Appian Records enable you to do more with your data. Regardless of where your data lives, Appian allows you to organize your data into actionable records that allow users to access and update the information that they need.
For example, think about an employee record. What information about the employee would you want to see? You'd probably want to have the employee's name, title, department, and start date readily available. What might you want to do? At some point you would likely have to update the employee's information. You might also need to add a new employee. These common actions can be directly added to your record type and can be referenced in other interfaces and processes.
This tutorial will take about an hour and walk you through the steps to create a basic record type for the employee data in your data store entity (DSE).
Record types are made up of your data, the record list, and the records themselves. This tutorial will walk you through creating a record type in three phases: (1) adding the source data, (2) configuring your record list, and (3) creating your record views and actions.
In the first phase, we will bring together our data and record type to begin connecting our users with the data. To do this, we will:
In the second phase, we will structure the way that our users will initially interact with the set of records through the record list. To do this, we will:
In the third phase, we will create a way for users to drill into and act upon each record. To do this, we will:
After successfully completing this tutorial, you will be ready to create your own record types.
If you are interested in learning about Process Backed Record Types, see the Process Model Tutorial.
We will be working with many different design objects:
To successfully complete this tutorial, you must have already completed the Application Building Tutorial and you should be familiar with building interfaces and creating process models. If you are new to Appian and unfamiliar with these concepts, check out Appian Academy Online.
Before we can create our record type, we need to create an application and add the data for our record type. We will also create a group to set visibility and a folder to hold our rules and constants.
To get started with this tutorial you must first create the Appian Tutorial application and have completed the Application Building Tutorial. In this tutorial we will be using the application, groups, and folders created in the application building tutorial.
Now that you have your application, groups, and a folder created, we will add a new group for Managers
.
AT Managers
.AT Administrators
.While we are doing all the prep work for this tutorial, we will make a folder to save rules and constants. To create a rule and constant folder:
AT Rules and Constants
.AT Administrators
group with Administrator.
We will be saving all our expression rules, constants, and interfaces in this folder throughout the tutorial.
Before we can create a record type, we will first create a custom data type (CDT), data store, and DSE to reference and hold the data that we will be adding for our records.
To populate the data for our records, we will be using the Use the Write to Data Store Entity Smart Service Function with an Interface.
No matter where your data lives, you can add it as a source for your record type. Before we configure the ways that users will view or act upon the records, we need to first point the record type to the data source. In the first phase of this tutorial we will be creating our record type, naming it, setting security, and using the data from our DSE as our data source.
By creating a record type, we will be configuring the way that your data is displayed in the record list, how users interact with your data through record views, and making your data actionable for users through related actions.
Employee
.
Employees
. This is the name that your users will see when they view the record type from Tempo.Directly after creating your record type, you need to add the object security.
To set object security:
AT Administrators
.Once you have your record type created and the security set, we need to tell the record type where the data lives. Since all of the data that we will be using for this record type is referenced using a DSE, we will set that DSE as its source.
To set the data source for your record type:
The record list displays all of the records, shows a few fields of key information about each record, and allows users to easily filter records. Users can also create new records directly from the record list with a list action. In the second phase of this tutorial we will be configuring the record list by selecting the columns of data that the users will want to see displayed in the list. Then we will create a constant for our employee department list. We will end the phase by using the department constant to create a user filter for users to be able to filter the records in the list.
We are going to configure the fields displayed in the record list so that they reflect the data that we want users to see at a glance before they drill into each record. When looking at a list of employees, we really only want to see their name, title, and department. To configure the record list to show only these columns, we are going to remove the ID column, combine the first and last name columns into one, and add a column for employee title.
To edit the record list:
Next combine the first and last name columns into one Name
column:
First Name
to Name
.lastName
.rf!firstName & " " & rf!lastName
.Remember the extra space between quotation marks in the middle so that there is a space between the first and last names in the label.
We will now add a column for the employee's title:
Title
.title
.rf!title
.Setting the sort field allows the user to easily sort the data in that column, such as Name by first or last names, and setting the display value let's the column know which record field to show.
Now we are going to create a constant for our department list that we will be using to set up our user filter and in an update employee interface later on. We will create a constant to define a set of options that our users will select frequently. This allows users to select a department filter on the record list, instead of entering a department in a field every time.
To set up a new constant with a text array:
AT_DEPARTMENT_LIST
.In the Value box, enter the department options. Separate each department by a line break, but do not include spaces, commas, or quotations:
1
2
3
4
5
Engineering
Finance
Sales
Human Resources
Professional Services
With the columns that we want to display in the record list configured and a department constant created, we will add a user filter so that users can easily filter employee records by department from the record list. We will be using the department constant along with a!foreach()
to make creating and maintaining our user filter easier.
To add a new user filter:
Department
.In the Filter Expression field, copy and paste the following expression:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
a!recordFilterList(
name: "Department",
options: a!forEach(
items: cons!AT_DEPARTMENT_LIST,
expression: a!recordFilterListOption(
id: fv!index,
name: fv!item,
filter: a!queryFilter(
field: "department",
operator: "=",
value: fv!item
)
)
)
)
By using the department constant, we don't have to manually update the filter if the department list is changed. We are using an a!forEach function here for the same reason. For more information, see Expression-Based User Filters.
You can also set up default filters in your record type so that users can see filtered record list results by default. For more information on configuring and using default filters, see default filters.
In the final phase of this tutorial we will be configuring the records within the record type by creating a record view and a related action. Record views can display relevant information about a user in each record. Our summary view will show information about each employee, but you can configure record views to show a variety of relevant and related information. These could be expense reports, time off requests, or issued employee equipment.
After we have added the summary view, we will also create a related action so that users can update the information about an employee from the record view. To make the related action, we will create a reusable interface and a process model.
Now that we have our initial set of records, we will make our employee summary view and add it to the record type.
First, we will create an interface for our record summary view. The interface will display a summary of each employee's information and be the first record view that a user sees when they open a record.
Then, we will create an expression rule that queries the DSE to get employee information. We will use this to test our interface so that we can view it with the employee's data. We will also be using this expression rule to query employee information when we add the summary view and related action to record type.
Next, we will add the summary view interface to the record type as a record view. Then we will configure the record header background color and the record title with the employee's name.
Now we will create an interface so that we can display the data that we want to see in each record.
To create an employee summary interface:
AT_summaryView
.AT Rules and Constants
.This will automatically populate all the fields, set them as read-only, and make the component labels adjacent. The adjacent labels in this design pattern are a best practice for creating a read-only interface that will be viewed but not edited, such as a summary view. For more information on read-only UX designs, see UX labels.
Now that you have the summary view interface configured, we will create an expression rule to query employee information by the record ID. This ensures that we are able to view the employee information in the summary view.
We will use this expression rule to help us test our interface and as a query to get employee data when we add the interface as a summary view in our record type. We will also be using this rule later on with the related action and list action steps.
To create our expression rule:
AT_getEmployeeById
.AT Rules and Constants
.id
.Copy and paste the following expression into the expression editor:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
a!queryEntity(
entity: cons!AT_EMPLOYEE_ENTITY,
query: a!query(
logicalExpression: a!queryLogicalExpression(
operator: "AND",
filters: {
a!queryFilter(
field: "id",
operator: "=",
value: ri!id
)
},
ignoreFiltersWithEmptyValues: true
),
pagingInfo: a!pagingInfo(
startIndex: 1,
batchSize: 1
)
),
fetchTotalCount: false
).data
With our expression rule created, we are going to add it to our summary view interface as a test value. We are using the record ID 1 to pass in the record data to the summary view so that we can see the fields populated with employee data.
rule!AT_getEmployeeById(1)
.We have created our employee summary interface and tested it with our expression rule, so we will now add the interface as the summary view for the record type. We need to call the employee ID rule into the expression rule for our summary view to help pull record data into the summary view.
To add the summary view to the record type:
rp!id
. This calls in the record ID as a record property. The expression should look like this:
rule!summaryView(employee: rule!AT_getEmployeeById(id: rp!id))
.Remember that since we have a rule input in the summary view interface, we need to call the information required by the rule input inside of the interface rule. Rule inputs are used to pass data into the expression rule.
We need to fill that parameter with the employee data from the selected record, so we use the getEmployeeById
rule and call in each record ID using the rp!id
. This is because we added an ID field as a rule input for our expression rule. Rp!id
pulls the ID record property and inputs that information in the expression rule.
While we are on the Views page, let's go ahead and configure a record header background and title. The record header background contains and displays the title, breadcrumbs, and related actions on every record view of your record.
You can opt for no background or you can set an image or color. We are going to configure a gray background:
#666666
to select a dark gray color.Now, we'll configure the record title so that it will show the employee's first and last name. We are adding the employee's name as a record title so that a user landing on this page will understand what they are looking at without having to navigate to the record list. To show the employee's name, concatenate the record fields of firstName and lastName.
rf!firstName & " " & rf!lastName
.Now that we have a summary view set up to view employee information, we are going to add a related action to update the record. We don't just want to be able to view the employee information, we want to take action on it directly from the record. For this example, a manager, HR representative, or the specific employee looking at an employee's record would frequently need to make updates to that information.
We will create a related action for managers to update employee information that will be accessible from the summary view. To create a related action, we will create a reusable interface and a group constant in this step and then a process model in the next step.
Before we make a new interface, we'll be making a constant to point to the manager group so that we can configure the visibility of the related action. Though there are multiple user roles that could need access to this action, we will be narrowing it down to just managers for this example. In the future, keep in mind which users will need to have access to view related actions.
Constants are a useful way to reference groups for setting conditional visibility on record views and related actions. We will set one up for our managers group so that we can make sure that they are the only users editing employee information.
To make a group constant:
AT_MANAGERS_GROUP
.Group
.AT_Rules and Constants
.We will now make a reusable interface for our related action that we will also use later on in our list action. The reusable interface will show the same employee information as the summary view, but the fields will be editable.
Reusable interfaces allow us to use the same interface multiple times instead of having to create multiple similar interfaces. To make this interface functional for both the related and list actions, we will write two expressions to conditionally show the different form labels and conditionally make components editable depending on the action.
The first set of steps will be similar to the way that we set up the interface for the summary view.
To make a reusable employee interface:
AT_createEditEmployee
.AT Rules and Constants
.Once the interface with the fields from your data type has been generated:
Department
.---Select a Department---
.cons!AT_DEPARTMENT_LIST
to call in the department constant.rule!AT_getEmployeeById(1)
.You will see all the employee's information appear in the fields.
Now we are going to configure two expressions for our form label and the start date field so that this form will work with our related action and list action. We need to add an expression for our form label so that it will show "Update Employee Information" when managers are using the related action or "Add New Employee" when managers are adding an employee record.
If we are updating the employee's information as part of the related action, we will be acting on a record. This means that the values for the record fields and in our rule input will not be null. If we are adding a new employee, these fields will be null. We will use if() in this expression.
In the Form Layout:
1
if(ri!employee.id, "Update Employee Information", "Add New Employee")
This expression simply says that if the rule input or rule input ID field is null, the label will read "Add New Employee". If the rule input or the ri!id field is not null, then the label will read "Update Employee Information".
We will do something similar for the Start Date field, but using not() and isnull(). If we are updating the employee information, we won't be changing the start date of the employee.
To configure the Start Date field:
Enter the following expression:
1
not(isnull(ri!employee.id))
The not function returns either true or false. This means that if the rule input ID field is not null, the field is disabled. If the rule input ID field is null, the field is not disabled and you can edit it.
Now that you have set up your reusable interface, we can move on to creating a process model to update the employee's information. We will be going through the steps to create a simple process model for our related action.
The process model will consist of the reusable interface as a start form, a cancel flow to end the process if the user cancels the action, and a write to data store entity smart service to save the updated employee information to our employee DSE. Then, we will add the process model as a related action to our record type and make it available from the summary view.
If you need more information or if you haven't created a process model before, check out the Process Model Tutorial or Appian Academy Online's course for help.
When we are finished, we will have a process model that looks like this:
To create a process model with a start form:
Update Employee
.AT Process Models
.
AT Administrators
.AT Managers
.Once inside the process modeler:
AT_createEditEmployee
.Creating a cancel flow is a best practice because cancel buttons are configured in the same way that submit buttons are. This means that without a cancel flow, the information in the form will be submitted and written to the DSE even if the user wanted to cancel the action.
To create a cancel flow:
Update Canceled
.Cancel Update?
cancel
is true, then we want the process to go to the "Cancel Update" node.=true
to configure the value so that it is true. Your expression will look like: pv!cancel=true
.Update Canceled
node.To add our data in the first few steps in this tutorial, we used the Write to Data Store Entity Smart Service as a function in an interface. Here, we are using the same Write to Data Store Entity smart service as a node in the process model to save our data to the DSE from the start form.
To add and configure a Write to Data Store Entity smart service node:
Write to Employee DSE
.employee
.pv!AT_employee
.Now that we have our process model almost complete, we are going to add activity chaining. Activity chaining allows the process to move quicker between nodes by chaining them together. We are going to add activity chaining between the start form and the Write to Data Store Entity node so that after updating the employee information on the summary view, the fields will be updated without having to refresh the page.
Activity chaining is usually used between multiple user input tasks and between user input tasks and write to data store entity nodes. Overusing activity chaining outside of these cases could slow down process performance.
To add activity chaining:
You are now ready to save, publish, and test your process model.
To save and test your process:
For more information on testing and debugging process models, see Testing and Debugging Problems with Process Models.
Now that we have the interface and process model working, we will return to the record type to set up the related action.
To add your process model as a related action:
Update Employee
.Update Employee
.rule!AT_getEmployeeById(rp!id)
in place of null. The cancel parameter should still be null.Since we don't want everyone to be able to update the employee information, we are going to make sure that only those in the manager group are able to access this related action.
To set visibility for the related action:
isusermemberofgroup(loggedinuser(),cons!AT_MANAGERS_GROUP)
.The combination of these two functions with the group constant checks to make sure that the logged in user that is trying to access the related action is a member of the managers group.
While we are here, we will change the icon to a pencil to differentiate multiple related actions. You can learn more about icons in the UX design guide.
Now we will add our related action to the summary view so that users can also update employee information if they need to while viewing the employee summary.
To add the related action to the summary view:
Now you can access your update employee related action right from the summary view!
When you are setting up record views and related actions on your own, you will need to consider what information your users need to see, what actions your users will need to take to update the data, and which users will be able to access the actions and record views.
You have successfully completed all the steps to create a record type with a DSE as its source! The next step walks you through how to add a list action to your record type. Many record types use both data store entities and processes to get their data, but it's not required for all record types.
The last step of this tutorial is to create a list action. This step will show you how to add a process model to your record type so that users are able to write to the DSE to create new records. You will build an add new employee process model that follows the same steps as the update employee process model and uses the same reusable interface. Though the record type already has a process for adding data to create records, this step creates an action for users to be able to add new records directly from the record list.
While some records use only data store entities or only process models as the source of their data, many developers use both for their applications. This step will show you how to connect a process model to your record type as a list action. List actions are used to create new records and are accessible from the record list.
We will use the AT_createEditEmployee interface that we set up earlier and create a process model to add new employee records to the employee record type.
Follow these same steps for setting up a process model as you did for the related action:
Add New Employee
and set security.AT_createEditEmployee
as the start form and add parameters.Now let's add our reusable interface and process model as a list action.
To add a list action:
Add New Employee
.Add New Employee
.isusermemberofgroup(loggedinuser(),cons!AT_MANAGERS_GROUP)
to set the visibility to managers only.plus
icon.Remember that the list action button will appear on your record list page and not on the record views like a related action would.
You did it! You made it through all of the phases and steps to successfully create a fully functioning record type with a summary view, related action, user filter, and a list action. You are now ready to create record types that enable your own unique business data to do more all on your own!
On This Page