This article provides detailed design information about the Record Type design object and its configuration options. To learn how create a new record type, see Create A Record Type.
The Properties section allows you to modify the name and description of the record type.
|Singular Record Type Name||The name of the record that is displayed in the Appian Designer. For example, Prospective, Customer, or Support Ticket.|
|Plural Record Type Name||The name of the record type in plural form. Visible to end users in Tempo under the Records tab. For example, Prospectives, Customers, or Support Tickets.|
|Record List URL||Contains a link to the record list for the record type in the end user interface. You can use this link to quickly navigate to the record list in the end user interface for testing.|
|Description||The description of the record type shown both in Tempo under the Records tab and in Appian Designer. For example, "Prospective customers bringing new business", "Current customers of the business", or "Issues reported by customers".|
The Data section allows you to define the data source for your record type. There are three data source options for records. See the tutorials for a detailed walkthrough on configuring those sources.
|Source||The source of the record data. For a service-backed record, select Expression.|
|Data Store||The source data store. For entity-backed records only.|
|Entity||The source data store entity. For entity-backed records only. Each row in the data store entity is a record.|
|Process Model||The source process model. For process-backed records only. Each active (unarchived) process instance is a record.|
|Data Type||The custom data type corresponding to the record. For service-backed records only. Fields of this data type are available for use with the record field domain (
|Expression||The source expression returning a value of type DataSubset. For service-backed records only. The result of this expression is used both for the records shown in the record list and data passed into the record view.|
Note: for entity-backed records, the entity you choose as the source must have a defined primary key (as opposed to an automatically generated one).
See also: Record Security
The Default Filters section allows you to set filters to apply to the source data to control which records appear. When a record is filtered out by a default filter, it does not show up in the record list, it is not returned in queries on that record type, and users may not access its views. You can apply multiple default filters to a record type. All filters are joined by an AND union. The filters do not control access to the underlying data sources.
User filters allow users to apply filter criteria to a record list to view a subset of the records. Each user filter can have one or more filter options. For example, a user filter named Region might contain five options: North America, South America, Europe and Middle East, Asia and Pacific, Africa. Users can select one or more of the filter options, depending on the filter configuration, to see records that meet the filter criteria. Filters that are configured to support the selection of multiple options will return all records that match at least one of the selected options.
When multiple user filters are present on the record list, users can select filter options for each of the defined user filters. The records returned are based on the records that meet the criteria of all the user filters combined. For example, a record list may have both a Status and Region filter. The Status filter has the "New" and "In Progress" options selected. The Region filter has the "Europe" option selected. The records returned will be the records that have a status of “New” OR “In Progress” AND Region is “Europe".
User filters may be defined with static options or with an expression.
The following properties are configured for a static user filter.
|Filter Name||Name displayed to designers in the User Filters list when editing the record type.|
|Filter Field||The field of the record type to filter by.|
|Filter Label||Expression that defines the name of the user filter displayed to end users. For example,
|Filter Visibility||Determines whether the filter is visible to the user at runtime. Default is
|Set default option||Enables designers to configure an expression that determines which, if any, filter option is applied when a record list first loads. This value should match the label of the intended default filter option.|
|Users can select multiple options||Enables designers to configure the filter as a single select or multiple select dropdown. Default is
The following properties are configured for a static user filter option.
|Option Label||Expression that defines the name of the filter option displayed to end users. For example,
|Operator||The comparison operator to filter with.|
|Value||An expression that returns the value(s) for the
|Value 2||An expression that returns the upper bound value for the
The following properties are configured for an expression user filter.
|Filter Name||Name displayed to designers in the User Filters list when editing the record type.|
|Filter Expression||The expression for the user filter. Configured with a!facet and a!facetOption.|
The record list displays all of the records of a given record type that a user has the right to view and any user filters configured for the record type. Users access the records from this list.
Each record type can have a grid-style record list or a feed-style record list.
Designers configure columns of record data for a grid-style record list using an easy point-and-click designer. End users can sort and page in the grid to find certain records. Record search in the grid-style list is across all record fields used in a grid row.
The following properties can be configured for the grid-style record list:
|Empty Grid Message||The value that displays when there are no records due to security, search, or applied filters.|
|Columns||The data columns to show in the grid. Details about column configurations are described in the table below.|
|Rows to Display Per Page||The maximum number of records visible to users at a given time. Users can use the paging controls to see more data.|
|Default Sort Field||The record field on which to sort when the record list first loads.|
|Default Sort Order||The order in which to sort when the record list first loads.|
The following properties can be configured for each column in the grid-style record list:
|Label||The label that appears as the column header.|
|Help Tooltip||The tooltip that appears in the column header.|
|Width||Column width. Valid values are
|Weight||Determines how wide distributed columns are in relation to each other. Valid values include integers from 1 (default) to 10.|
|Sort Field||The record field on which to sort when a user sorts this column. If no value is selected, the column is not sortable.|
|Alignment||Alignment of the column heading. Valid values are "LEFT" (default), "CENTER", and "RIGHT".|
|Component||The type of component to show in the column. Components will be read-only. Depending on the chosen component, the designer can configure other details about that component. Available components are text, integer, decimal(), date, date & time, image, link, progress bar, and rich text|
|Visibility||Determines whether the column is displayed on the interface.|
Designers configure an expression to show a feed-style list using a!listViewItem. Designers also configure default sort field and order. Only the first 100 records display in the record list. Record search in the feed-style list is across all the record fields used in the title parameter of
Designers can allow record viewers to export filtered record lists to Excel. This setting displays an Export to Excel button on a record list that record viewers can click to download a copy of their filtered record lists in Excel.
Designers can configure the title, views, and related actions that are available for an individual record.
Each record has a title that appears at the top of each record view, in record tags, and in the hover card for that record. For grid-style record lists, designers configure a specific expression for the record title. For feed-style record lists, the record title comes from the title parameter in
A record view is an interface for users to view data for a specific record. You can create multiple views for a single record type (up to 20 additional record views). Users access them by selecting a record from the record list. The Summary view displays by default. Users access all other SAIL views configured for the record from the links at the top of the record.
The layout and data that display for each record is determined by the expressions used to define the Summary view and additional views configured as part of the record type.
See also: Record View Security
Related actions allow users to act on a record or in the context of that record. Process-backed records derive related actions from the model’s quick tasks, and records of any source type can be configured to have related actions that start process models. For example, for a record that represents a customer, there might be a related action to enter a new order for that customer or to update the information about that customer.
All related actions configured for a record type are available on the Related Actions view for records. You can also make specific related actions to be available to end users from record views by configuring related actions shortcuts for the relevant record views.
See also: Related Action Security
Security can be configured for the record type as a whole, as well as for various objects within the record type.
Each record type has a rolemap specifying its Viewers, Auditors, Editors, and Administrators. One or multiple groups can be added to each role. Users must also have at least viewer rights to the source to view a record in Tempo. By default, only the record type creator and system administrators have access to the record type.
Users in each role are allowed to perform the following actions on the record type:
|Actions / Roles||Administrator||Editor||Auditor||Viewer|
|View in Tempo||Yes||Yes||Yes||Yes|
If users have viewer rights to the record’s source, restricting them from viewing records through record type security does not stop them from viewing the associated data in other areas of the system.
See also: Manage User Rights and Security
Individual record security is based on the security of the underlying source. Users must have at least viewer rights to the record’s source to view the record in the record list or to view its record views.
For example, applying a default filter to hide a specific group of processes will stop those records from generating, but the process data might still be visible in a process report or process dashboard.
The security of the record’s source is configured differently for the different source types:
For process-backed records, see also: Configuring Process Security
For service-backed records, the source expression executes in the context of the user viewing the record list. Even if the source expression is defined using a rule, the security role map applied to that rule does not prevent any users from executing the rule by viewing the record list. Access to the underlying data must be controlled by the designer of the rule in its definition in conjunction with the access control mechanisms available from the provider of the data. For instance, if the rule retrieves data from an external data provider that requires credentials for authentication and authorization, the rule designer must build the retrieval and presentation of those credentials into the definition of the rule.
See also: Expression Rule Security
Security for record views is a combination of the source security, record type security, and default filter configurations.
A user must be able to view a record in the record list to to access the record. Anyone with access to the record will see the Summary view by default. If a user does not have access because of source security, record type security, or a default filter configuration, the user cannot access the record views even if given a direct URL.
Each additional record view also has its own security. This is based on the visibility expression defined for the view. Users may access additional record views by navigating in Tempo or by using a record link that is configured to go to a certain view. Record links respect record view visibility.
NOTE: Hiding data on a view does not secure the underlying data. It only determines what does not display on the view.
Security for starting related actions is based on the security of the underlying process model. Users can only start a related action if they can view the record and have initiator rights to the action’s process model. The same applies for quick tasks that appear as related actions for process-backed records. If the user does not have the rights to complete the quick task, the link to the related action will not display under Related Actions.
See also: Configuring Process Security
When configuring a record type, you can reference record fields using the
rf! domain prefix. For example, if your data source has a field called "name," you can reference the values in that field with
For process-backed records, you can use the
rf! domain prefix to reference process and process-model properties. The following sections list the process and process model properties available to the record type. To call those properties, put
rf! in front of the reference. For example,
rf!pp.initiator will return the initiatior of a process.
Process properties can be referenced in process-backed records.
To reference a process property, use the process property prefix (
pp.) in front of the reference. This must still be from within the record field (
rf!) domain: (
All process properties in the below table can be referenced this way. For example, to reference the process Start Time, use
||Integer||System-assigned ID for the process. Process IDs are unique within an Appian instance. They are not reused, and can be used to reference the process throughout the application.|
||Text||Name of the underlying process model.|
||Text||The value set as the process priority. Note: this is a descriptive property. It is available to designers to use how they see fit, but the property itself does not affect how Appian handles the process.|
||User||The user who started this process.|
||User||Owner of the underlying process model. If there are multiple process administrators, the user who last updated the process model becomes the owner.|
||Date/Time||Time the process was started.|
||Date/Time||The date/time value set as deadline. Note: this is a descriptive property. It is available to designers to use how they see fit, but the property itself does not affect how Appian handles the process.|
||Text||Time zone context used by the process. This value may differ from the configured process model time zone, such as when the designer selects the option to override the configured process model time zone with the process initiator's time zone. See also: Time Zone Context|
Process model properties can be referenced in process-backed records.
To reference a process model property, use the process property prefix (
pm.) in front of the reference. This must still be from within the record field (
rf!) domain: (
All process properties in the below table can be referenced this way. For example, to reference the process model Time Zone, use
|Process Model Property||Reference||Type||Description|
||Integer||System-assigned ID for the process model. Not to be confused with the UUID.|
||Text||Name of the process model.|
||Text||Description of the process model.|
||Text||Version of the process model.|
||User||Creator of the process model.|
||Text||Time zone the process model was created in.|
||Text||Unique identifier for the process model application object.|