Record definition concepts - Documentation for BMC Helix Innovation Studio 22.1

TermDescriptionExampleRecord or record definition

A record definition is a collection of the data required for building the application for your business process. A record definition is made up of specific record fields.

A task can be stored as a record definition.Record field

A unit of information that collectively forms a record definition. A single record definition consists of multiple fields, and each field has one or multiple attributes.

The task record definition can consist of the following fields:

• Task ID
• Assignee
• Description
• Submitter
• Status
• Due date

Record instance

The data created by the application for which the structure of the data is specified by the record definition.

The task fields can consist of the following record instances:

• Assigned to: Seth
• Priority: Critical

Index

In a record definition, an index is a list of record fields that are frequently searched. Indexes reduce the database search time and optimize the performance of your Digital Service application by returning search results faster.
You can index the fields that users frequently search for. However, you should use indexes carefully because adding too many indexes to a single record definition may lead to performance degradation.

 A record definition for a task can consist of the following index entries:

• Status
• Created Date

CustomizationAs is the case with most kinds of definitions, an administrator can control whether the record definition is customizable after it is deployed to a production environment. This is controlled at the level of the entire record definition, or if desired, for individual fields. Also the administrator can permit only permissions to be customized but nothing else.The administrator only allows Status and Description to be customized. Permissions can be customized for all fields.Permissions

Access to the record definition itself, or individual fields, can be restricted to a list of Roles (these are created in the Administration tab of BMC Helix Innovation Studio). There is also a special group called Public that be assigned if the field is open to anyone.

Administrators map these Roles into actual Groups of real users after deployment.

The administrator restricts access to a Salary field to users whose group is mapped to the HR role.Security Labels

This is another kind of permission control, but works on individual record instances so they are dynamically assigned at runtime. The Security Label implies a relationship with one or more Groups or Roles. Only users who have that relationship will be able to view or modify the record instances.

Specifying the Security Label in the record definition is not enough to give access. Rules must be created to set or remove the labels from specific record instances at runtime.

There is a Cost field. It is given a Security Label called AccountingSensitive. At runtime, this Security Label is applied only if this particular record meets guidelines that make it significant to the Accounting Department. At runtime, only such records are visible to members of the Accounting Department.Inherit from a Record DefinitionIf desired, the record definition can automatically inherit all the fields from another record definition. You can then choose whether to also inherit core fields, Rule bindings, Field Permissions, and Associations.Request inherits from Ticket. All the fields from Ticket are implicitly there as part of Request. If a new field is later added to Ticket, it automatically shows up as part of Request.Share Data with Inheritors

If selected, this option means that any other record definitions that inherit from this one will store their data in the same database table as this one. This means that a query for these Records will return the inheriting records also (though not their particular fields, just the common ones).

If this is not set, then the fields are inherited but the data is stored in a separate database table and there is no way to query them together.

Location is set to "share data with inheritors". Site, inherits from Location but adds the field SiteID. Therefore if you query Location you will see all the Locations including all the Sites, but you will not see any site-specific data such as SiteID.AbstractThis means that the record definition only exists for purposes of inheritance. Actual record instances should never be created.Ticket is an abstraction to define the shared fields of Incident, Problem, and Change. We don't want actual Ticket record instances created so we make it Abstract.FinalThis means that new record definitions cannot inherit from this one.The extended business logic requires that there be no further extension of the Change record definition, so we lock out further inheritance here.Exporting Data

This means that when a developer exports the bundle definitions in order to create a Deployment Package, all record instances of this definition are exported along with it. When it is deployed to a production environment, the records are imported and replicated for all tenants currently existing on the production environment.

Typically this is NOT used for operational data, such as Incidents or Tasks. It is generally used for data which is used for configuration purposes, such as data used for Named Lists.

We create a record definition to store the names of processes to be invoked from a Named List. Since we ship these processes with the application, we should specify that the data be included with the Deployment Package as well.Allowing Users to DeleteTypically, only administrators should actually delete data. This setting enforces this globally for all records of this definition.There is some frequently generated data that users can completely clean up if they choose to, so we set this option to be True.