In this article, you will learn how to create and configure a record type that can be accessed from the Records tab. For guided walkthroughs on creating records, check out our tutorials.
A record type allows you to define a set of records from your business data and processes, and create views for that data that you can make available to your users. Before creating a record type, it may be helpful to review how records are used in Tempo.
Record types are created in Appian Designer.
Open the destination application for the new record type.
Click New, then choose Record Type from the dropdown menu.
Fill out the Create Record Type form.
Once you’ve named and described your record type, you can click Create & Edit to start editing the record type immediately, or click Create to just create the object.
Every record type needs a data source defined that consists of a set of records. This can be a table or view within your data store, the running processes of a process model, or an external data source.
This section explains how to configure each within the Data section of the record type.
Any data store entity can be used as the source for a record type. Every row in that entity will be treated as an individual record of your record type. This is known as an "entity-backed record." This is the most common type of record, and is the easiest to configure.
To create an entity-backed record,
Select Data Store Entity from the Source dropdown.
Click on the Data Store dropdown to select a data store from your application.
Click on the Entity dropdown to select an entity from the selected data store.
Any process model can be used as the source for a record type. Each running instance of that process model will be treated as an individual record of your record type. This is known as a "process-backed record." This type of record is less common, and can be a little more challenging to configure. It may be helpful to do the Records Tutorial, which has a section on process-backed records.
To create a process-backed record,
Choose Process Model from the Source dropdown.
Enter the name of the process model in the Process Model field.
Any expression that results in either a data subset, dictionary, or a list of the selected custom data type can be used as the source for a record type. Each row in the data subset will be treated as an individual record of your record type. This is known as an "expression-backed record." This type of record is most commonly used to create records from external data sources, and can be a little more challenging to configure. We recommend newer users do the Expression-Backed Records Tutorial.
To create an expression-backed record,
Choose Expression from the Source dropdown.
Enter a custom data type in the Data Type field. This custom data type must match the data contained in each record of the data subset.
Enter the expression that returns a list of records in the List View Source Expression field. The expression must return either a data subset, a list of the selected custom data type, or a dictionary. Each row maps to the selected custom data type.
Enter the expression that returns an individual record in the Record View Source Expression field. The expression must return either a data subset, the selected custom data type, or a list of the selected custom data type.
By using two expressions, designers no longer need to add logic to decide whether to display a list view or a record view. Also, designers no longer need to cast the result of an expression to a data subset.
The following variables are available in the
rp! domain respectively to provide easy access to them:
rsp!searchText: The text entered by end users in the record's list search box.
rsp!pagingInfo: The paging and sorting configurations applied to the record list.
rsp!filters: An array containing the record type's default filters as well as the user filter selections.
rp!id: The id of the record type instance. Accessible from the record view source expression only.
We recommend using the variables listed above instead of using the the query object by using
The record list is the list of records the user sees once they’ve clicked on this record type from the Records tab in Tempo.
The record list can be displayed as a feed or a grid. When the list is a feed, each record is displayed in a vertical list like a news feed. When the list is a grid, the records display in rows like a spreadsheet.
In the screenshot below, you can see the same set of records displayed in both a feed (left) and a grid (right).
One of the advantages of a grid-style list is the ability to sort on columns. By default, new record types are created with a grid-style list.
You can allow users to export record lists that are displayed as a grid to Excel. Simply select the checkbox under the Record List section that allows users to see an Export to Excel button. Record viewers can click this button to download a copy of their filtered record lists in Excel.
For additional information, see: Optimizing Record Lists for Export to Excel.
Grid-style record list is the default list for new record types. The grid-style list is configured with a new interface that is much like the design view of an interface. This interface allows you to easily navigate and configure the components of this grid.
To give your records a title that will display at the top of every record view, go to the Record View Details section and enter a title in the Record Title field. This is an expression field, so encase text values in quotes.
To configure your grid-style list, go up to the Record List section and click Edit Record List.
If this is a new record, you'll notice that there's already a grid configured here. We grab a few columns from your data source just to get you started. We also put a record link component in the first column so users can click to the record directly.
Don't worry, you're not stuck with this grid; you can add, remove, and change any column. If you’ve worked with the design view before, this interface should be familiar.
There are three main levels to the record grid that you can easily navigate from the navigation panel on the left: (1) Grid level, (2) Column level, and (3) Component level.
A grid’s general settings allow you to set which columns to display, how many rows to display per page, and the default sort when the list is first opened.
(A) In the navigation pane on the left, Grid is the highest level available. You can always click here to return to these settings.
(B) Under Columns, you can choose which columns to display and in which order. You can also add a new column here by clicking Add Column at the bottom of the column list.
(C) Here you can set some paging information, including how many Rows to Display Per Page, the Default Sort field, and whether the sort should be Ascending or Descending.
(D) Click Test at any time to refresh the grid preview. This resets sorting so you can preview how the grid will look when it's first loaded in Tempo.
For a full list of grid properties, see Grid-Style Record List.
You can configure a number of settings related to a column, including its label, width, alignment, etc.
To edit a column’s settings, click on any column name in the navigation pane on the left, or click on its label in the Columns section of the Grid settings.
In the below screenshot, I’ve set the Label for column #4 to "Contact," and I made the column sortable by selecting PurchaserName from the Sort Field dropdown. When the user clicks the title of this column, it will sort by the values in the PurchaserName field.
If you don't set a Sort Field for a column, users won't be able to click on that column to sort it.
Every column can have one component. If your column does not have a component yet, in the Component section, click Select Component, and choose the desired component type. To edit an existing component, simply click on the component’s name.
In the above screenshot, the component in this column is a text component with the Display Value of rf!PurchaserName.
At the component level, values must be called with the record field domain (
rf!). Every field in your data source is available as a record field.
For a full list of available components, see Grid-Style Record List.
A feed-style record list is vertical list of records that resembles a news feed. This is an alternative to the grid-style list in the previous section.
The feed-style list is created with the listViewItem function.
A feed-style record list cannot display more than 100 records. If the record set includes more than 100 records, and searching by record title won't help users find the records they're looking for, we recommend you Create User Filters, or consider a Grid-Style Record List.
To create a feed-style record list, from the Record List section, select Feed, then click Edit Record List.
This will display a form into which you can enter your list view function and choose a field to sort on.
You’ll notice that record values are called with the record field domain (
rf!). Every field in your data source is available as a record field.
The first record in the above image has been color coded against the
listViewItem function so you can see how the parameters display.
Many users find it helpful to create the list view in a separate expression rule and call that rule here.
In this example, the record image itself (in the image parameter) is called from a rule that returns an image for each record based on the record’s status. Below is the rule we used to choose the appropriate image.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 load( local!status: choose(wherecontains(ri!status,cons!CASE_APP_OrderStatus), "EYE", "CLOCK", "WARNING", "PAPER_AIRPLANE", "TASK" ), local!color: choose(wherecontains(ri!status,cons!CASE_APP_OrderStatus), "BLUE", "GREY", "ORANGE", "GREEN", "GREEN" ), a!iconNewsEvent(local!status,local!color) )
A record list action is a link to a process model the user can start directly from the record list. It is common to configure this action for users to create a new record for that record type.
To create a record list action,
Default filters allow you to filter records before they are loaded in the record list. Records filtered this way are completely inaccessible to the user, and won't show up in searches or queries by that user. For more information about default filters and record type security, see Default Filters.
Each default filter defines a condition that must be true for a record to display in the list. If you have multiple conditions, the record must meet all conditions in order to display.
You can create a default filter using the following options:
To create a default filter,
Enter the record field to check in Field. You don't need to use the rf! prefix.
Select the appropriate comparison from the Operator dropdown.
Enter the value for the comparison in the Value field. This is an expression field, so encase text values in quotes.
For example, the filter in the following screenshot removes all records with a status of Closed.
User filters, like default filters, allow you to define conditions that must be true for a record to display in the list. Unlike default filters, users filters are controlled by the user, and are available from the top of the record list.
Every user filter can have multiple options created for it, and you can have multiple user filters. User filters can be simple or dynamic.
You can create new user filters using the following options:
Note: expression-backed records cannot use simple user filters.
Enter a name for the user filter in Filter Name. This is the name it will display within the record type, in the User Filters table.
Enter the field you want to filter against in Filter Field. Note: you don't need to use the
rf! domain here.
Enter the name you want users to see in Filter Label.
By default, user filters are visible to all users who can see the record type. If you want to restrict the visibility of a filter, click Only show when… from the Filter Visibility section. Doing so displays a field into which you can enter an expression.
The filter will display when the expression evaluates to true.
Now it's time to create some filter options. Each one of these will display under the filter dropdown at the top of the record list. When the user clicks on one of the options, it'll filter the records for all that match that condition. Multiple options can be selected at a time from a single user filter by default. To change the filter to only allow a single selection, uncheck the "Users can select multiple options" field. To create a new filter option,
Click + New Filter Option.
Enter a name for the option in Option Label. This is the name users will see.
Choose the appropriate condition from the Operator dropdown. This is how your chosen record field will be compared.
Enter a value the condition must meet in Value. This is the value your record field will be compared against.
You can choose one of your options as the Default Filter Option, which means when a user first loads the record list, this option will already be selected. They can clear the option by clicking on it, if they want to choose another.
To choose a default option, select the Set default option checkbox. This will open the expression editor. Enter in an expression that evaluates to one of the option labels defined in the user filter.
Instead of configuring a simple user filter, you can construct a dynamic user filter with an expression using the a!facet() function. For expression-backed records, this is the only option. However, you can use an expression to configure a user filter for process and entity-backed records as well.
For configuration information and examples, see the Dynamic User Filters page.
A record view is an interface that allows you to display record information to users. These are defined in the Record View Details section, under Views, where you will find a tabular display of the record type's views.
If you do not have a record view created yet, we recommend creating your record views as separate interface objects, and then passing the record information to those interfaces when calling them from the record type. To learn more about this method of creating a record view, see Create a Record View.
At a minimum, all records must have the Summary view, which is the default view for a record.
The summary view is the first view a user sees when they click on a record from a feed-style record list. To define a summary view,
In the Record View Details section under Views, click Summary.
This will open the Edit View form.
Enter an expression that calls your record view in the Interface field.
You can add additional views to a record (up to a maximum of 20 additional record views).
To add another view to a record, open the record type and click + New View, under Record View Details.
This will open the Create New View form.
Enter the name you want the user to see in the View Name field. This is an expression field, so encase text values in quotes.
Enter your interface expression, or an expression that calls your interface, in the Interface field. For an example, see part three of Create a Record View.
Enter an expression to set the visibility for the view in the Visibility field. The view will only be visibile when the expression evaluates to true for the user.
From Related Action Shortcuts, select the related actions you want to display as buttons for this view. This section is blank if you haven't added any to the record type yet. The next section explains how to add related actions.
Related actions are links to process models the user can start directly from the record view with information about that record. We call that information the context for the related action. We recommend limiting related actions to processes relevant to the specific record from which they are started. To learn more about how related actions work from records, see Related Actions and Starting Processes From an Interface.
Related action process models are same as any other process model, except for a start-form restriction: if the process model has a start form, that form must be a SAIL form. This restriction doesn't apply to Quick Tasks.
Before you can add a related action to a record view, you must first add it to the record type. To do so,
Open your record type.
From the Related Actions section, click + New Related Action.
Enter the Display Name of the related action.
Enter the Description of the related action. If the display name is using the process model name, the description will automatically use the process model description.
Select the icon you wish to display with the related action in the Related Actions list in the Icon field.
Select the process model you wish to use as a related action in the Process Model field.
null, and adds a comment with the data type for reference. Simply replace the
nullwith the value you want to pass to the process parameter, as shown below. You do not need to include all parameters from the process model; only include the parameters you need for the related action, and remove the rest. If you make changes to the process parameters later, you'll need to manually update this field.
To further restrict who can access the related action, update the Visibility expression field.
Now that you've added you related action to the record type, it'll be visible from the Related Actions view of your records.
If you want the related action to show up as a button in the upper-right-hand corner of a record view, you'll need to go back to the Record View Details section and open the desired view.
From there, you should see your available related actions on the right under Related Action Shortcuts.
Simply check a box next to the ones you want to display on this view.
Related actions from Quick Tasks won't show up in this list.
Users will see selected related actions as buttons when they are on that particular record view. Different views can display different related actions.
In the below example, you can see our record type has two related actions available to add to the Summary view: Update Order Status and New Request.
Within the record type designer, access the Security option in the Settings menu to define who will be able to see and/or edit your record type.
By default, users and groups that are not system administrators or explicitly in the rolemap of a record type do not have access to see it. However, you can change the default security for a record type such that all users have Viewer privileges.
There are three permission levels available related to record type access. In summary, they are:
For more detailed information about record type security, see Security.