Record Types

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.

Properties

The Properties section allows you to modify the name and description of the record type.

Field Description
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".

Data

The Data section allows you to define the data source for your record type. There are three data source options for records. The following sections describe the fields for each source of data. See the tutorials for a detailed walkthrough on configuring those sources.

Data Store Entity

Field Description
Source The source of the record data. For an expression-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.

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

Process Model

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

Expression

Field Description
Source The source of the record data. For an expression-backed record, select Expression.
Data Type The custom data type corresponding to the record. For expression-backed records only. Fields of this data type are available for use with the record field domain (rf!).
List View Source Expression The source expression returning the list view of the record type. Returns either a value of type DataSubset, a dictionary, or a list of the selected custom data type. For expression-backed records only.
Record View Source Expression The source expression returning the record view of the record type. Returns either a value of type DataSubset, the selected custom data type, or a list of the selected custom data type. For expression-backed records only.

Record Type Variables

The following variables are available in the rp! and rsp! domain respectively and provide easy access to elements inside the rsp!query variable:

  • rp!id: The id of the record type instance. Accessible from the record view source expression only.
  • rsp!filters: An array containing the record type's default filters as well as the user filter selections.
  • rsp!pagingInfo: The paging and sorting configurations applied to the record list.
  • rsp!query: (Deprecated) The record type’s grouping, aggregation, filtering, paging, and sorting configuration to be applied when querying record data. Use rsp!filters, rsp!pagingInfo, and rsp!searchText instead.
  • rsp!searchText: The text entered by end users in the record's list search box.

Migrating a Record Source Expression

Prior to 18.3, designers had to configure a single Source Expression field containing an expression for both the records shown in the record list and data passed into the record view.

Starting in 18.3, the Source Expression field is split into the following:

  1. List View Source Expression, which defines the list view of the record type.
  2. Record View Source Expression, which fetches data for an individual record.

These two new expressions provide a more logical and easier way to configure each expression based on its purpose. The following example illustrates how to update an existing expression-backed record from using a single source expression to the list view & record view source expressions.

Assume the source expression field contains the expression below and notice the following:

  1. The expression first checks whether there is a record type instance. If rp!id is null, it calls the UMD_CourseListingSourceExpression integration to fetch the elements of the record list.
  2. If a record type instance is available, it calls the UMD_CourseListingSourceExpression function to obtain data for an individual record. And then:
    1. It casts the results into the corresponding data type (i.e. type!{urn:com:appian:types}UMD_Course)
    2. Creates a datasubset using the resulting data type (local!course) and the id of the record type instance (rp!id)
if(isnull(rp!id), 
  rule!UMD_CourseListingSourceExpression(
    filters: rsp!filters,
    searchText: rsp!searchText,
    pagingInfo: rsp!pagingInfo
  ),
  with(
    local!course: cast(
      'type!{urn:com:appian:types}UMD_Course',
      rule!UMD_getCourse(rp!id).result.body
    ),    
    a!dataSubset(
      data: {local!course},
      identifiers: {rp!id}
    )
  )
)

By using the list view & record view source expressions, designers will no longer need to perform the null check in step 1. Also, steps 2.1, and 2.2 are no longer required.

Instead, a designer can simply:

  1. Copy the expression that renders the record list into the list view source expression:
  rule!UMD_CourseListingSourceExpression(
    filters: rsp!filters,
    searchText: rsp!searchText,
    pagingInfo: rsp!pagingInfo
  )
  1. Copy the expression that fetches a single record into the record view source esxpression: rule!UMD_getCourse(rp!id).result.body
  2. Comment out the source expression, so it is not executed.
  3. Save and test the updated record type.
  4. Delete the original source expression (assuming both the record list and record work correctly).

After deleting the source expression and reloading the record type, the source expression will no longer be displayed.

See also: Record Security

Default Filters

With default filters, the designer can control which records appear 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.

Deisgners can add default filters either By Field or using an Expression:

By Field

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

Screenshot

Expression

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

Screenshot

These filters do not control access to the underlying data sources. Expression-backed records only support default filters using an expression.

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:

/*
(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 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 as either simple or dynamic.

Simple User Filters

Simple user filters allow you to create a filter with fixed options.

The following properties are configured for a simple user filter.

Field Description
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, ="Location" displays as Location.
Filter Visibility Determines whether the filter is visible to the user at runtime. Default is Always show.
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 true.

The following properties are configured for a simple user filter 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.

Dynamic User Filters

The following properties are configured for a dynamic user filter.

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

Record List

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.

Grid-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:

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

Feed-Style Record List

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 a!listViewItem.

Show Export to Excel Button

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.

Your export will reflect 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 doesn't exceed 1,000.

For additional information, see: Optimizing Record Lists for Export to Excel.

Record List Action

Designers 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. Users return to the record list after completing the action.

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 doesn't already exist. It also allows designers to use their 5 site pages more efficiently by combining record and action functionality.

Record Details

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

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 access them by selecting a record from the record list. The Summary view displays by default. Users access all other 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

Security can be configured for the record type as a whole, as well as for various objects within the record type.

Record Type Security

Each record type has a rolemap specifying its Viewers, 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 Viewer
View in Tempo Yes Yes Yes
View properties Yes Yes Yes
View security Yes Yes Yes
Update properties Yes Yes No
Update security Yes No No
Delete object Yes No No

Notes

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

Record 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 entity-backed records, see also: Configuring Data Store Security and Record Level Security for Entity Backed Records

For process-backed records, see also: 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 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

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 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

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 initiatior 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.
FEEDBACK