Record Type Object

This page provides detailed design information about the record type object, its configuration options, and how to reference it in an expression. See Create A Record Type for how-to information on creating a new record type object.

In order to use new record type object components, features, or functions, such as the Record Action Component, you must update your record type objects created before Appian 20.1. All legacy record type objects include the following update alert at the top page.

Record Type Update Message

To update a legacy record type, simply open the record type object from the Appian Designer Objects View and click the Update button at the top of the page. Appian will automatically update your record type to the latest version.

You cannot update legacy expression-backed records created before Appian 20.1. In order to use new record type object components, features, and functions, you must recreate these legacy expression-backed records using the latest Appian version.

Properties

The Properties menu (located in the gear icon) allows you to modify the name and description of the record type.

Field Description
Singular Record Type Name The name of the record type 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.
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".
Tempo Display Determines when a record type will display on the Tempo Records tab. Record types display by default.
Icon An icon associated with the record type shown in Tempo under the Records tab. The Appian Record icon is used by default.
Icon Color The color of the icon associated with the Record Type. You can provide a hex code or Appian expression to define icon color. Icon is Accent by default.

Note: Electing to not display a record type does not prevent users from viewing a record type's list or views in Tempo.

Source

All record type objects require a data source. You can create a new record type object and open it from the Appian Designer Objects View. All record type objects have a Source & Default Filters page that allows you to select the data source for your record type. There are three data source options: data store entity, process model, and expression. The following section describes the fields for each data source.

See the tutorials for detailed guidance on configuring each data source.

Data store entity

Select Data Store Entity when you want to use a data store table or view as the source for your record type.

Field Description
Source The source of the record data. For an entity-backed record type, select Data Store Entity.
Data Store The source data store. For entity-backed record types only.
Entity The source data store entity. For entity-backed record type objects only. Each row in the data store entity is a record.

For entity-backed record types, the entity you choose as the source must have a defined primary key.

Process model

Select Process Model when you want to use the running processes of a process model as the source for your record type.

Field Description
Source The source of the record data. For process-backed record types, select Process Model.
Process Model The source process model. For process-backed record types only. Each active (unarchived) process instance is a record.

Expression

Select Expression when you want to leverage a web service as the source for your record type. This selection allows you to call an integration and transform the response into the data that backs your record type.

Field Description
Source The source of the record data. For expression-backed record types, select Expression.
Data Type The custom data type (CDT) that corresponds to the record type. The record field domain prefix (rf!) allows you to reference fields of this data type.
Data (DataSubset) The Record Data Source expression that calls the integration for your record and returns a DataSubset for the record list view. The data parameter of this DataSubset should contain an array of dictionaries that map to the selected data type. Note that this is not the record data that is used to fetch the data for a single record, for which you must configure the Data (Dictionary) field for the Single Record Source.
Paging Info The rule input of the Record Data Source expression that passes the paging and sorting configuration of the record list. The selected rule input must be of type PagingInfo.
Search Text The rule input of the Record Data Source expression that passes the search query string that runs against the record list. The selected rule input must be of type Text.
Data (Dictionary) The Single Record Source expression that calls an integration and returns a dictionary that maps to the selected Data Type. This integration will be used to fetch the data for a record when rendering a record view, launching a related action, or using a!recordLink() to define a record link.
Record Identifier The rule input that corresponds to the record identifier (ID) for the Single Record Source expression. The value of this unique identifier is used to return the data for a single record.

Record data source

The RECORD DATA SOURCE configuration section is where you'll configure the data for your record type. This section allows you to configure the integration that pulls in your external data source, the expression rule that calls your integration, and the rule inputs that define your paging, searching, and filtering parameters.

wizard rds connected system create

Single record source

The SINGLE RECORD SOURCE configuration section is where you'll configure the data for a single record view. This section allows you to configure an integration that pulls in the data for a single record view, the expression rule that calls in the integration, and the rule input that defines the Record Identifier for the record view that returns when the integration is called.

wizard srs integration create

Testing expression-backed records

After configuring the expression rules that call the integrations for your record type, you can use the Test Record Source box to verify that the data results returned for your Record Data Source expression and Single Record Data expression are correct. Simply select the view for the source expression you want to verify and click the TEST button.

record type test pane

The results of your Record Data Source expression will be cast to the Data Type you selected for your record type, and displayed in a grid. Although this view may look similar to the record list view you configured, it is not the same. Rather than showing your configured columns, the Test Record Source view will show you the values of each available field in the rf! domain. These fields can be used as inputs when configuring your Record List.

record type test pane source view

You can also use this view to evaluate your rule inputs for paging, searching, and filtering. The rule inputs for these parameters apply to your record list view so you'll want to ensure they're working as expected.

When you select the Single Record Source view, you will see the expression output cast to your selected Data Type. This displays all of the fields and values available for a single record. You can also select how you want the fields and values for a single record displayed in the view, Formatted, Raw, or Expression.

record type test pane single record

See Expression-Backed Record Tutorial for detailed guidance on configuring the Record Data Source and Single Record Source fields and using the Test Record Source pane to verify your record type views. The Test Record Source interface displays the first 100 records from your DataSubset only.

See the Appian 20.1 documentation for information about expression-backed record types created on Appian 20.1 or earlier.

Default filters

With default filters, the developer can control which records appear in the record list and views by applying filters to the source data. 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.

Developers can add default filters either By field or using an Expression:

Default filters are not applicable for expression-backed records. Instead, you can use the expression rule for the Record Data Source to conditionally filter out records.

By field

Developers can apply multiple default filters to a record type. All filters are joined by an AND union.

record default filters

Expression

Developers can also specify more complex filters by entering an expression containing a list of a!queryFilter() or a!queryLogicalExpression().

/record default filters expression

These filters do not control access to the underlying data sources.

The following sample expression returns cases that are either assigned to the logged in user, or are not assigned to the "Global Users" group but are either Urgent or High priority:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
/*
(Assigned to User OR (NOT Assigned to "Global Users" AND (priority="Urgent" OR priority="High")))
*/
if(isusermemberofgroup(loggedInUser(),cons!CASE_GROUP_GLOBAL_VIEWERS),
  {},
  a!queryLogicalExpression(
    operator: "OR",
    logicalExpressions: {
      a!queryLogicalExpression(
        operator: "AND",
        filters: a!queryFilter(
          field: "userName", 
          operator: "=", 
          value: loggedInUser())
      ),
      a!queryLogicalExpression(
        operator: "AND",
        logicalExpressions: {
          a!queryLogicalExpression(
            operator: "AND",
            filters: a!queryFilter(
              field: "userName", 
              operator: "<>", 
              value: cons!CASE_ADMIN_DB_KEY_1)
          ),
          a!queryLogicalExpression(
            operator: "OR",
            filters: {
              a!queryFilter(field: "priority", operator: "=", value: "Urgent"),
              a!queryFilter(field: "priority", operator: "=", value: "High")
            }
          )
        } 
      )
    }
  )
)   

User filters

User filters offer the ability to filter subsets of record data by selecting options in a list or using a date range style filter. Developers can configure user filters through a guided experience or with an expression for all record types except expression-backed record types, which use a guided experience.

List style user filters can have one or more filter options. For example, a 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 there are more than 11 filter options, the filter includes a search box to help users find filter options.

Date Range filters may also be added allowing precise record filtering between two dates or an open-ended range where only a start or end date is provided.

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 Hire Date filter. The Status filter has the "New" and "In Progress" options selected. The Hire Date filter has "1/1/2008 - 12/31/2014" selected. The records returned will be the records that have a status of "New" OR "In Progress" AND fall between "1/1/2008 - 12/31/2014".

Once users select any filter options, they can also save their selections by choosing Set as default from the filters menu. These saved filter values will apply by default whenever they load the record list.

User filters may be defined using either a Guided or an Expression-based approach. The user filter preview gives you real-time feedback on the filters you build.

User filters for service-backed records are configured differently than user filters for other record types. To learn more, see User Filters for Expression-backed Records.

Guided user filters

List filters

List-style user filters allow you to create a filter with fixed options.

The following properties are configured for a guided-list user filter.

Field Description
Filter Name Name displayed to developers 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, ="Location" displays as Location.
Filter Visibility Determines whether the filter is visible to the user at runtime. Default is Always.
Set default option Enables developers 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 developers to configure the filter as a single select or multiple select dropdown. Default is true.

The following properties are configured for a guided-user filter list option.

Field Description
Option Label Expression that defines the name of the filter option displayed to end users. For example, ="North America" displays as North America.
Operator The comparison operator to filter with.
Value An expression that returns the value(s) for the = and <> operators or the lower bound for the between operator.
Value 2 An expression that returns the upper bound value for the between operator. This field only appears on the form if you selected between as the value for the Operator field.

Date range filters

Field Description
Filter Name Name displayed to developers in the User Filters list when editing the record type.
Filter Field The field of the record type to filter by.
Default From Determines which, if any, starting date is applied when a record list first loads.
Default To Determines which, if any, ending date is applied when a record list first loads.
Filter Visibility Determines whether the filter is visible to the user at runtime. Default is Always.

Date range filters are not yet supported for expression-backed records created with Appian 20.1 and later. However, they will continue to work for expression-backed records created with Appian 19.4 and earlier. See User Filters for Expression-backed Records for more information about configuring filters for expression-backed records.

Expression-Based user filters

The following properties are configured for an expression-based user filter.

Field Description
Filter Name Name displayed to developers in the User Filters list when editing the record type.
Filter Expression The expression for the user filter. Configured with a!recordFilterDateRange for dates or a!recordFilterList and a!recordFilterListOption for other types of data.

User filters for expression-backed records

The following properties are configured to define user filters for a expression-backed record.

Field Description
Filter Name Name displayed to developers in the User Filters list when editing the record type.
Filter Label Expression that defines the name of the user filter displayed to end users. For example, ="Location" displays as Location.
Rule Input Name of the rule input from the Record Data Source Expression to which the selected value(s) for this filter is passed
Filter Visibility Determines whether the filter is visible to the user at runtime. Default is Always.
Choices The expression for the user filter. Configured with a!recordFilterChoices.
Users can select multiple choices Enables developers to configure the filter as a single select or multiple select dropdown. Default is true.
Default Choice Enables developers to configure an expression that determines which, if any, filter choice is applied when a record list first loads. This value should match the label of the intended default filter choice.

Expression-backed records created using Appian 20.1 and later allow you to use the rf! domain to directly reference filters and actions within the record type and removes the need to create a constant to indirectly reference these record fields in the record type.

Record list

The record list is a responsive display of all of the records for a given record type and any filters configured for the record type. You can configure a grid-style record list or a feed-style record list that users, with rights, have permission to view.

Grid-Style record list

A grid-style record list organizes and displays your record data in tabular view. From the List page, you can use the Edit Record List modal to configure columns of record data for a grid-style record list. End users can sort and page in the grid to find specific records and search across all record fields used in a grid row for records that match a specific search query.

The following properties can be configured for the grid-style record list:

Field Description
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:

Field Description
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 "DISTRIBUTE" (default), "NARROW" and "ICON".
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 are read-only. Depending on the chosen component, the developer 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.

Feed-Style record list

Another option is the feed-style record list, which displays all of the records for your record type in a vertical list. You can use a!listViewItem in an expression to configure a feed-style record list, with a default sort column and order. In the feed-style record list, only the first 100 records display in the record list. End users can search the record list across all of the record fields used in the a!listViewItem title parameter.

Show export to Excel button

Developers can allow record viewers to export filtered record lists to Excel. This setting displays as an Export to Excel button on a record list. Record viewers can click the button to download a copy of their filtered record lists in Excel. The exported file will show the record list's current sort for process-backed and expression-backed record types.

Entity-backed record types will only be sorted if the filtered number of rows does not exceed 1,000.

See Optimizing Record Lists for Export to Excel for additional information.

Record list action

Developers can allow record viewers to quickly launch an action from the record list by using the record list action. Currently, only one action can be configured per record type and any process model can be selected. A record list action can be configured to open in a dialog box, the same tab, or a new tab. After completing the record action, users return to the record list. When actions are configured to open in a dialog, any user filter values are remembered when returning to the record list.

A common use case is to add an action to create a new record. This allows users to leverage the record list search to ensure the record in question does not already exist. It also allows developers to use their 5 site pages more efficiently by combining record and action functionality

Record details

Developers can configure the title, headers, views, and related actions that are available for an individual record.

Title

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, developers can configure a specific expression for the record title. For feed-style record lists, the record title comes from the title parameter in a!listViewItem.

Headers

The record header appears at the top of each record view as the background and contains the title, breadcrumbs, and related actions. By default, the record header style is "NONE". Developers can configure their backgrounds with a color or image.

Color headers can display one background color for all records in a record type, or many colors based on an expression or variables within the record.

You can also configure image backgrounds to display one image or multiple images. One image from a document or a URL can be used for all records in a record type. Similar to color headers, you can also configure image backgrounds to display different images based on variables within the record or using an expression.

Image headers display the record title, breadcrumbs, and related actions on top of the image in an overlay. You can customize the style, type, and position of the overlay.

See also: Create a Record Type

Views

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 can access views for a single record by selecting the record from the record list. The Summary view displays by default. Tabs underneath the record header allow users to access all other views configured for 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 Record View Security for more information.

Related actions allow users to act on the record type within the context of a specific subset of record data. Process-backed records derive related actions from the process model’s quick tasks. You can configure records of any source type to have related actions that start a process model. For example, within a customer record, there might be a related action to enter a new order for that customer or to update the customer information.

All related actions configured for a record type are available on the record's Related Actions view. You can also configure related actions shortcuts, for relevant record views, to make specific related actions available to end users from the record views.

See How to reference a record list action or related action and Related Action Security for more information about referencing record actions and configuring security for a record.

Referencing a record type from an expression

A record type object reference allows you to directly call an existing record type in your expression using the recordType! domain. This domain prefix is a direct object reference that removes the need to create a constant to reference your record type, except in specific use cases. See When to use a constant for more information.

Record type object references also allow you to access and reference the record actions of the record type for use in the record action component.

See Record Action Component for more information.

How to reference a record type

After creating a record type, use the recordType! domain to reference the record for use in functions, such as queryrecord() and urlforrecord(), and components, such as a!recordLink() or a!pickerFieldRecords(). For instance, in the example below, the recordType! domain is used to reference the Employee record type:

record type employee lozenge

After entering the recordType! domain in an expression, a type ahead will suggest existing record types for you to select and reference within your expression. The record type must exist and you must have access to the existing record type in order to reference it.

See queryrecord(), urlforrecord(), Record Link, Record Picker Component, and Record type security for more information.

After adding a record list action or related action, use the recordType! domain to reference the record action. Record actions cannot be referenced using a constant.

Since record types are specified to each environment, this example does not evaluate in your Test Rules interface. Use it only as a reference.

  1. Use the recordType! domain to add a reference to the record type. For example, the record type reference below calls the Employee record.

    record type employee lozenge

  2. Use dot notation to append the .actions property to the recordType!<Record Name>. Type ahead will suggest all existing record list action keys that you have access too when you type a dot after .actions.

    record type employee actions lozenge

  3. Select a record action key from the type ahead to append the action key to the record type object reference. For example, the reference below calls the update employee information record action for the Employee record.

    record type employee actions update lozenge

See also: Record Action Component

When to use a constant

There are specific use cases that still require you to use a constant to indirectly reference a record type. For example, when using the Report Builder to create basic grids and charts from a record type's data, you must first save the record type as a constant and use the constant to select the record type in the Report Builder. You must also use a constant or expression rule, which references the record type, to call a record type in an existing process modeler.

See Use the Report Builder and Working with Data in Process for more information.

Security can be configured for the record type object, as well as for the various objects and data referenced within a record type. See Layered Object Security to learn more.

Record type security

Users must have at least Viewer permissions to a record type to access it in Tempo or on a site. Additionally, for Tempo, the record type must be configured to display in the Records tab.

The security role map of a record type controls which users can see or modify it and its properties. By default, only the record type creator and system administrators have access to the record type. See Editing Object Security to modify a record type's security.

The following table outlines the actions that can be completed for each permission level in a record type's security role map:

Actions Administrator Editor Viewer
View record type in Tempo Yes Yes Yes
View record type definition Yes Yes Yes
View the security Yes Yes Yes
Update record type definition Yes Yes No
Update the security Yes No No
Delete the record type Yes No No

Note: Preventing users from being able to view a record type does not secure the record type's underlying data source. Users may still be able to view the underlying data in other areas of Appian.

Record security

Individual record security is based on the security of the underlying source. Users must have at least Viewer permissions 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 entity-backed records, see Configuring Data Store Security and Record Level Security for Entity Backed Records.

  • For process-backed records, see Configuring Process Security.

  • For expression-backed records, both the list view and record view source expressions execute in the context of the user viewing the record list. Even if these source expressions are defined using rules, the security role map applied to those rules does not prevent any users from executing the rule by viewing the record list. Access to the underlying data must be controlled by the developer 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 developer must build the retrieval and presentation of those credentials into the definition of the rule. For more information, see Expression Rule Security.

Record view 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 permissions to the process model for the action. The same applies for quick tasks that appear as related actions for process-backed records. If the user does not have the permissions to complete the quick task, the link to the related action will not display under Related Actions.

Referencing record fields

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 rf!name.

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 initiator of a process.

Process properties

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: (rf!pp.<reference>).

All process properties in the below table can be referenced this way. For example, to reference the process Start Time, use rf!pp.startTime.

Process Property Reference Type Description
ID id 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.
Name name Text Name of the underlying process model.
Priority priority 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.
Initiator initiator User The user who started this process.
Designer designer User Owner of the underlying process model. If there are multiple process administrators, the user who last updated the process model becomes the owner.
Start Time startTime Date/Time Time the process was started.
Deadline deadline 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.
Time Zone timeZone 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

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: (rf!pm.<reference>).

All process properties in the below table can be referenced this way. For example, to reference the process model Time Zone, use rf!pm.timeZone.

Process Model Property Reference Type Description
ID id Integer System-assigned ID for the process model. Not to be confused with the UUID.
Name name Text Name of the process model.
Description description Text Description of the process model.
Version version Text Version of the process model.
Creator creator User Creator of the process model.
Time Zone timeZone Text Time zone the process model was created in.
UUID uuid Text Unique identifier for the process model application object.

See also: Configuring Process Security

Open in Github

On This Page

FEEDBACK