Record definition concepts
Term | Description | Example |
|---|---|---|
Record or record definition | A record definition is a collection of data required for building the application for your business process. A record definition includes specific record fields. | A task stored as a record definition. |
Record field | 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:
|
Record instance | The data created per the structure defined in the record definition. | The task fields can consist of the following record instances:
|
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. | A record definition for a task can consist of the following index entries:
|
Customization | An administrator can control whether the record definition is customizable after it is deployed to a production environment. The customization is controlled at the level of the entire record definition or for individual fields. Users can customize only the fields that are marked customizable by the administrator. An administrator can also allow users to customize the field permissions. | The administrator allows Status and Description to be customized, and also allows Permissions to be customized for all fields. |
Permissions | Access to the entire record definition or individual fields is restricted to a list of roles. There is also a special group called Public that is assigned if the field can be accessed by anyone. Administrators map these roles to groups after deployment. | The administrator restricts access to a Salary field to users whose group is mapped to the HR role. |
Security Labels | Security Labels work on individual record instances and are dynamically assigned at runtime. It 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 to users. You must create Rules to set or remove the labels from specific record instances at runtime. | The administrator gives a Security Label called AccountingSensitive to a Cost field. At runtime, the records with the Cost field are visible only to the members of the Accounting department. |
Inherit from a Record Definition | If this option is selected, a record definition can automatically inherit all the fields from another record definition. You can then choose to also inherit core fields, rule bindings, field permissions, and associations. | Consider an example where the Request record inherits data from the Ticket record. 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 this option is selected, the inherited records will store its data in the same database table as the parent record. This means, when you run a query for these records, the results will display the parent and the inherited records. It will however, not include any specific field added to the inherited records. If this option is not selected, only 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. |
Abstract | This means that the record definition only exists for purposes of inheritance. Actual record instances should never be created. | Ticket record definition. You create it as an abstraction to define the shared fields of Incident, Problem, and Change. |
Final | This 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 you make it final to lock further inheritance of this record definition. |
Exporting Data | When a developer exports the bundle definitions 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 in the production environment. Typically, this is not used for operational data, such as Incidents or Tasks. It 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. Because we ship these processes with the application, we should specify that the data be included with the Deployment Package as well. |
Allowing Users to Delete | Typically, 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 True. |
Record field concepts
Term | Description |
|---|---|
Type | Fields 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. |
If the record definition itself is customizable, the administrator can further specify which fields can be customized. |
Types of record definitions
A record definition can be of two types: regular record and join record.
Regular record
A regular 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 record searches for fields that have corresponding values in 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.
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 International Standard Book Number (ISBN) value is used as a criteria to create an inner join record.
An inner join record contains only the entries in which the join criteria exists in both the primary and secondary records. In this example, the join record produces a report that shows only the titles that are checked out by the customers.
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.
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 International Standard Book Number (ISBN) value is used as a criteria to create an inner join record.
An outer join 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 binds the external data in AR Systemforms 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.