This documentation supports the 21.02 version of BMC Helix Innovation Studio.

To view an earlier version, select the version from the Product version menu.

Record definition concepts

 This topic provides information about the concepts related to a record definition and a record field, and types of record definitions.

Record definition concepts

The following table lists the concepts in a record definition:

TermDescriptionExample
Record 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.

Record field concepts

TermDescription
TypeFields come in different types, and some of the properties of the types vary. For example, number fields have a min and max value. Character fields can have a Named List assigned to them, and can be encrypted. Selection fields have a list of enumerated values. The Record designer UI indicates which properties are appropriate for each type.
CustomizationIf the record definition itself is customizable (see above), then the administrator can further specify which fields are.

Types of record definitions

A record definition can be of two types: regular record and join record.

Regular record

A regular record is a record definition that is not a combination of multiple record definitions. 

Join record

A join record definition is a combination of data that is retrieved from multiple record definitions. Join record definitions are similar to database joins.

With join records, you can perform the following operations:

  • Retrieve data from multiple record definitions.
  • Specify the criteria for retrieving data from multiple record definitions. 
  • View or edit record fields of multiple record definitions at the same time.

Join records are further divided into inner join records and outer join records.

Inner join record

This type of join record combines only the matching data from multiple record definitions. An inner join searches for fields that have corresponding values in the multiple records and then combines the matching data to form a join record. If a field does not have a corresponding value in any of the records, that field is omitted from the join record.

Example of an inner join:

The following image illustrates the concept of an inner join. In the example, the Library Catalog form is the primary record, and the Customer Checkout form is the secondary record. The join criteria is the International Standard Book Number (ISBN).



An inner join creates a record that contains only the entries in which the join criteria exists in both the primary and secondary records. The join record produces a report that shows only the titles that are checked out.

Outer join record

This type of join record combines all the fields from a record definition that is marked as primary, even if the fields do not have a corresponding value in a record definition that is marked as secondary. To see all submitted help requests, including those that have no specific employee information connected with them, you can create an outer join.

Example of an outer join:

The following image illustrates the concept of an outer join. In the example, the Library Catalog form is the primary record, and the Customer Checkout form is the secondary record. The join criteria is the International Standard Book Number (ISBN).

An outer join creates a record that includes a comprehensive listing of all the catalog items from the primary record even if there is no corresponding data in the secondary record.

External record

An external record definition is a record definition that binds the external data (AR System forms) such that the external data appears in the BMC Helix Innovation Studio as a local record instance. The external record definitions can be used as regular record definitions, so that the objects such as View Components, Process, Rule, Named List can be bound to them just like regular Record Definitions. 

Was this page helpful? Yes No Submitting... Thank you

Comments