This page provides step-by-step guidance on creating a record type object to display employee information.
If you are new to Appian and unfamiliar with Appian design objects and concepts, check out Appian Academy Online.
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 a data store entity (DSE).
Record types are made up of record data, the records themselves, and a record list. This tutorial will walk you through creating a record type in three phases: (1) adding the source data, (2) creating your record views and actions, and (3) configuring your record list.
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 define different ways for users to view each record and add buttons so they can act on the information in each record. To do this, we will:
In the third phase, we will structure the way that our users will interact with the set of records through the record list. 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 record types that use a process model as their source, see the Process Model Tutorial.
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.
Ensure you are familiar with the different design objects that will be referenced throughout this tutorial:
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, a folder to hold our rules and constants, and a constant.
To get started with this tutorial you must first create the Appian Tutorial application and complete 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 determine how users will interact with your data through record views, make your data actionable through the use of related actions, and configure the way that your data is displayed in the record list.
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:
Now that we have our record data, we will configure the records within the record type by creating a record view and a related action. A record view displays information for a single record, and you can create multiple views to display the record information in different ways.
In this tutorial, we will configure a summary view to show information about each employee. After we define 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.
In this step, we will define the summary view of the record type. To do this, we'll first create an interface for our view. Then, we'll add the interface to the summary view in our record type. Lastly, we will configure the record header background color and the record title with the employee's name.
We will start by creating 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
.With your interface created, we can now add a component for each field of the record type.
To add components to the interface:
Now we want to add our Employee record data type as a rule input in our interface. This will pass the data for all fields into each record without needing an expression rule to query the data.
To add your record data type as a rule input:
Employee
.With our record data type added as a rule input, it's time to configure our components and connect them to the rule input.
To configure the components:
First Name
.Your interface should look like this:
Since this summary view is only for displaying record data, we set each field to read-only and made the component labels adjacent. The adjacent labels in this design pattern are a best practice for creating an interface that will be viewed but not edited, such as a summary view. For more information on read-only UX designs, see UX labels.
Record data types as rule inputs should only be used in interfaces that will be read-only views. They should not be used for interfaces that will be a part of a related action or process model.
We have created our employee summary interface, so we will now add the interface as the summary view for the record type. We need to use rv!record
in our interface rule for the summary view to pull record data into the view.
To add the summary view to the record type:
rule!
and the name of your interface.rv!record
. The expression should look like this:
rule!summaryView(Employee: rv!record)
.
rv!record
calls the data for each individual employee record and displays it in each record's summary view.When we combine record data type rule inputs and rv!record
, we are able to easily call in the data for each record and display that data in the record's summary view. The rv!record
reference knows the record that you're viewing and shows you the data for that record without you having to create an extra expression rule to query the data. This saves us time and simplifies the configuration of the record type.
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.
rv!record[recordType!Employee.fields.firstName] & " " & rv!record[recordType!Employee.fields.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. We will create the related action in two steps. In the first, we will create a group constant, a department constant, an expression rule, and a reusable interface. In the second, we'll create a process model.
Before we make an expression rule and 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
.Now we are going to create a constant for our department list so we can reference a set of pre-defined department names in our update employee interface. This constant allows users to only select from a pre-defined list of departments when updating the employee information, instead of entering a department in a field every time or entering a department name incorrectly.
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
Now that we have two constants, we only have one more object to create before we can create our reusable interface.
In this step, we will create an expression rule that queries the DSE to get employee information by the record ID. In the next few steps, we will use this expression rule to help us test our reusable interface, pull in employee data to work with the logical expressions in that interface, and pass in the correct employee data to the process models that we'll be creating.
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 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.
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.Before we move on to configuring some logical expressions, we're going to add our expression rule to the interface as a test value.
We are using the record ID 1 to pass the record data into the interface so that we can see the fields populated with employee data.
rule!AT_getEmployeeById(1)
.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:
Enter the following expression:
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:
Add or 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 and submit buttons are configured in the same way. 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.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
.Add or Update Employee
.rule!AT_getEmployeeById(ID: rv!identifier)
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:
a!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.
In the final phase of this tutorial, we will create the record list. 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.
We will be configuring the record list by selecting the columns of data that the users will want to see displayed in the 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, phone number, and start date columns, and combine the first and last name columns into one.
To edit the record list:
Next we will combine the first and last name columns into one Name
column. We will also add sorting to allow the users to easily sort data in a column, and set the display value to let the column know which record field to show.
To create the Name
column:
First Name
to Name
.lastName
.fv!row[recordType!Employee.fields.firstName] & " " & fv!row[recordType!Employee.fields.lastName]
.
With the record list columns configured, 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
.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: recordType!Employee.fields.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.
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 use the process model that we just created to update employee records as a process to add new employee records, as well. 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 process model that we just created for our related action as our list action. We can use this process model to add new employees because the reusable AT_createEditEmployee interface is our start form. The interface will evaluate whether or not there is an existing record and determine if the process needs to update a record or add a new one to the employee record type.
Let's add our reusable interface and process model as a list action.
To add a list action:
Add New Employee
.Add or Update Employee
.a!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!