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.

Introduction

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.

Objectives

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

   • Create our record type.
   • Add the data to our record type.

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

   • Define record views so that users can see specific record data through different perspectives.
   • Add related actions to allow users to update the record that they are viewing.

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

   • Configure the record list by selecting which columns we want to see in the list.
   • Create a user filter for users to filter the records in the list.

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.

Requirements

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:

• record types
• custom data types
• data stores
• interfaces
• constants
• expression rules
• process models

Set Up

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.

Create the Appian Tutorial application using the Application Building Tutorial

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.

Add groups

Now that you have your application, groups, and a folder created, we will add a new group for Managers.

1. From the NEW dropdown menu, select Group.
2. In the Name field, enter AT Managers.
3. In Group Members, enter your user name.
4. Click CREATE.
5. Click Add Users or Groups and enter AT Administrators.
6. Click SAVE.

Create a Rules and Constants folder

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:

1. From the NEW dropdown menu, select Folder.
2. For Type, select Rule Folder.
3. In the Folder Name field, enter AT Rules and Constants.
4. Click CREATE.
5. Configure the rule folder security by setting the default to Viewer and adding the AT Administrators group with Administrator.
   • All objects in this folder will inherit these security settings unless otherwise specified.

We will be saving all our expression rules, constants, and interfaces in this folder throughout the tutorial.

Add data using the Use the Write to Data Store Entity Smart Service Function on an Interface pattern

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.

Phase 1: Adding the source data

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.

Step 1: Create record type

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.

Create a record type

To create a record type:

1. From the NEW dropdown menu, select Record Type.
2. In the Name field, enter Employee.
   • Notice that when you click away from the Name field, the Plural Name field is automatically filled with Employees. This is the name that your users will see when they view the record type from Tempo.
3. In the Description field, enter a description for your record type. This description displays on the record type list in Tempo.
4. Click CREATE.

Set object security on your record type

Directly after creating your record type, you need to add the object security.

To set object security:

1. From the Permission Level dropdown list of the Default (All Other Users) row, select Viewer.
2. Click Add Users or Groups.
3. In the User or Group field, enter AT Administrators.
4. From the Permission Level dropdown list for the AT Administrators row, select Administrator.
5. Click SAVE.

Set data source

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:

1. On the left navigation menu, click Data Model.
2. Click TELL US ABOUT YOUR DATA.
3. For CHOOSE SOURCE TYPE, select Database.
4. Click NEXT.
5. For CHOOSE DATA STORE AND ENTITY, select the data store that you created during set up.
6. For Entity, select the employee entity that you created during setup.
7. Click FINISH.
8. Click SAVE CHANGES.

Phase 2: Define your record views and actions

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.

Step 2: Create a summary view interface

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.

Create an employee summary interface

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:

1. Go back to the application view.
2. From the NEW dropdown menu, select Interface.
3. In the Name field, enter AT_summaryView.
4. In the Save in field, enter AT Rules and Constants.
5. Click CREATE.

With your interface created, we can now add a component for each field of the record type.

To add components to the interface:

1. From the COMPONENTS tab under PALETTE, drag and drop the COLUMNS layout onto the interface.
2. Delete one Column Layout.
3. Drag and drop three TEXT components into the left column.
4. Drag and drop two TEXT components and one DATE component into the right column.

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:

1. Under Rule Inputs, click to add a new rule input.
2. In Name, enter Employee.
3. In Type enter the name of your record type.
4. Click CREATE.

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:

1. Click on the first text component in the left column to show the COMPONENT CONFIGURATION.
2. In Label, enter First Name.
3. For Label Position, select Adjacent.
4. For Display Value, hover over your Employee rule input, then select the firstName field.
5. Select the Read-only checkbox.
6. Follow these same steps for each component on the interface. You will have text components configured for Department, Phone Number, Last Name, and Title and a date component configured for Start Date.
7. Click SAVE CHANGES.

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.

Add summary view to record type

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:

1. Open the Employee record type and on the left navigation menu, click Views.
2. Click the record view called Summary.
3. In INTERFACE, call in your summary view interface using rule! and the name of your interface.
4. Inside of the interface rule, call the employee information for each record into our rule input using rv!record. The expression should look like this: rule!summaryView(Employee: rv!record).
   • Here, rv!record calls the data for each individual employee record and displays it in each record's summary view.
5. Click OK.

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.

Configure the record header background and title

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:

1. For Background, select COLOR.
2. For Color, select Static Color.
3. In the hex code text editor, enter #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.

1. In the Record Title expression editor, enter rv!record[recordType!Employee.fields.firstName] & " " & rv!record[recordType!Employee.fields.lastName].
   • Record type field references are specific to each record type and environment. This means that the reference used here won't work if you copy and paste it into your interface.
2. Click SAVE CHANGES.

Step 3: Create an update employee interface for a related action

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.

Make a group constant

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:

1. Go back to the application view and create a new constant.
2. In the Name field, enter AT_MANAGERS_GROUP.
3. Add a description.
4. In the Type field, enter Group.
5. In the Value field, enter your managers group.
6. In the Save in field, enter AT_Rules and Constants.
7. Click CREATE.

Create a department constant

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:

1. Go to the application view.
2. From the NEW dropdown menu, select Constant.
3. Select Create from scratch.
4. In the Name field, enter AT_DEPARTMENT_LIST.
5. For Type, select Text.
6. Check the Array box.

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

8. In the Save in field, select the AT Rules and Constants folder.
9. Click CREATE.

Make rule!AT_getEmployeeById

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:

1. Go to the application view.
2. From the NEW dropdown menu, select Expression Rule.
3. Select Create from scratch.
4. In the Name field, enter AT_getEmployeeById.
5. In the Save in field, enter AT Rules and Constants.
6. Click CREATE.
7. In the RULE INPUTS panel on the right, click in the top right corner to add a rule input.
8. In the Name field, enter id.
9. In the Type field, enter Number (Integer).

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

11. In the Ad Hoc Test panel, go to the expression box for Test Inputs and enter a valid record ID. We will use the record ID 1 throughout the tutorial.
12. Click TEST RULE. You will see the employee information displayed in the Test Output section.
13. Click Save Changes.

Create an update employee interface

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:

1. Create a new interface.
2. In the Name field, enter AT_createEditEmployee.
3. In the Save in field, enter AT Rules and Constants.
4. Click CREATE.
5. From the template pane on the right, select CREATE FROM DATA TYPE.
6. In the Data Type field, select your employee data type.
7. Under Generate an Interface for, select the Editing Data option.
8. GENERATE your interface.

Once the interface with the fields from your data type has been generated:

1. Delete the Department text field.
2. Replace it with a DROPDOWN field.
3. In the Label field, enter Department.
4. In the Placeholder Label field, enter ---Select a Department---.
5. In both the Choice Labels and Choice Values fields, enter cons!AT_DEPARTMENT_LIST to call in the department constant.
6. In both the Selected Value and Save Selection To fields, select the department field of your rule input from the rule input dropdown list.

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.

1. Click TEST.
2. In the Test Inputs expression editor for the employee rule input, enter rule!AT_getEmployeeById(1).
3. Click Set as default test values.
4. Click TEST INTERFACE. You will now be able to see the employee's information in the fields.
5. Click SAVE CHANGES.

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. Go to the Label field.
2. Click the Edit as Expression button.

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

1. In the Start Date component, scroll down to go to the Disabled parameter.
2. Click the Edit as Expression button.

3. Enter the following expression:

   1
   not(isnull(ri!employee.id))
   

4. Click SAVE CHANGES.

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.

Step 4: Create a process model for the related action

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:

Create a process model and a start form

To create a process model with a start form:

1. Go to the application view and from the NEW dropdown menu, select Process Model.
2. In the Name field, enter Add or Update Employee.
3. For Save in, select enter AT Process Models.
   • This folder was created in the Application Building Tutorial
4. Click CREATE.
5. Click Add Users or Groups and enter AT Administrators.
6. From the Permission Level dropdown list, select Administrator.
7. Add another group for AT Managers.
8. From the Permission Level dropdown list, select Initiator.
9. Click SAVE.

Once inside the process modeler:

1. Click the Properties button.
2. From the Process Model Properties window, click the Process Start Form tab, then click Select an interface.
3. In the text bar, enter AT_createEditEmployee.
4. When asked if you want to Create Process Parameters to match your interface's inputs, select YES. This adds the rule inputs from our interface into the process model.
5. Click OK.

Create a cancel flow

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:

1. Drag and drop an XOR gateway onto the process model line.
2. Drag and drop an End Event under the XOR gateway.
3. Click the End Event label and enter Update Canceled .
4. Connect the XOR gateway to the End Event.
5. Double-click the XOR gateway to open the node.
6. In the Name field, enter Cancel Update?
7. Click the Decision tab.
8. Click New Condition. We are setting up the condition so that if the process variable cancel is true, then we want the process to go to the "Cancel Update" node.
9. In the condition, click the Expression Editor button and select the process variable cancel.
10. Click Save AND CLOSE. The condition is already automatically set to is True.
11. From the Results dropdown list, select Update Canceled.
12. For the Else if none are TRUE condition, select go to the End Node.
13. Click OK.

Configure the write to data store entity 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:

1. Drag and drop the node between the cancel flow and the end node.
2. Double-click the Write to Data Store Entity node to open it.
3. In the Name field, enter Write to Employee DSE.
4. Go to the Data tab. Then go to the Inputs tab.
5. In Node Inputs, click Data Store Entity.
6. For Value, use the search feature to find your data store and select your employee entity.
7. Click New Input and name the input employee.
8. For Type, use the search feature to find and select your employee CDT.
9. For Value, select pv!AT_employee.
10. Click OK

Activity Chaining

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.

To add activity chaining:

1. On the line connecting the Start Node and the Cancel Update decision, double-click to open the Flow Properties dialog box.
2. For Enable Activity Chaining, select YES.
3. Click OK.
4. On the line connecting the Cancel Update decision and the Write to Employee DSE node, double-click to open the Flow Properties dialog box.
5. For Enable Activity Chaining field, select YES.
6. Click OK.

Process Model Debugging

You are now ready to save, publish, and test your process model.

To save and test your process:

1. Click the File button and select Save & Publish from the dropdown menu.
2. From the File dropdown menu, select Start Process for Debugging to test the process.
3. Add some test data and run through the nodes of the process using the Refresh icon () in the process model toolbar.
4. Test both the full process and the cancel flow.

For more information on testing and debugging process models, see Testing and Debugging Problems with Process Models.

Add related action to record type

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:

1. Open the Employee record type and on the left navigation menu, click Related Actions.
2. Click New Related Action.
3. In the Display Name field, enter Update Employee.
4. In the Process Model field, enter Add or Update Employee.
5. In the Context expression editor, your process parameters will automatically display. In the employee parameter, add 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:

1. In the Visibility expression editor, enter a!isUserMemberOfGroup().
2. In the first parameter, enter loggedinuser().
3. In the second parameter, enter the managers constant that you set up in step 6 for the managers group. The expression should look like this: a!isUserMemberOfGroup(loggedinuser(),cons!AT_MANAGERS_GROUP).
4. Click OK.

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.

Add the related action to the summary view

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:

1. On the left navigation menu, click Views.
2. Click the Summary view.
3. Under Related Actions Shortcuts, select the Update Employee box.
4. Under Open Actions In, select DIALOG BOX.
   • This option dictates whether your related action will open in a dialog box over the summary view, in a new tab, or on a new page in the same tab.
5. Click SAVE CHANGES.

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.

Phase 3: Configure your record list

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.

Step 5: Configure record list columns

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:

1. On the left navigation menu, click List.
2. Click EDIT LIST.
3. In the Columns section, delete the ID column by hovering over the three dots and clicking .
   • We don't need to show the ID column in the record list because the record field is primarily used by the database to identify records and not used by users.
4. Delete the phoneNumber and startDate columns in the same way.

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:

1. In the Columns section, delete the lastName column by hovering over the three dots and clicking .
2. In the Columns section, click First Name (Link).
3. In the label field, change First Name to Name.
4. In the Sort Field field, remove firstName and enter lastName.
5. Under Display Value, click Link.
6. Under Links, click List of Links.
7. Under Links, click Record Link.
8. Beside Label, click the Edit as Expression icon .
9. Change the label to the concatenated first and last names to show both values within the same field: fv!row[recordType!Employee.fields.firstName] & " " & fv!row[recordType!Employee.fields.lastName].
   • Record type field references are specific to each record type and environment. This means that the reference used here won't work if you copy and paste it into your interface.
10. Click OK.
11. Click SAVE CHANGES.

Step 6: Add a user filter

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.

Add new user filter

To add a new user filter:

1. Open the Employee record type and on the left navigation menu, click User Filters.
2. Click New User Filter and select Expression.
3. In the Name field, enter Department.
4. In the Filter Expression field, copy and paste the following expression:
   • Record type field references are specific to each record type and environment. This means that you will have to change the reference used here to work with your record type.

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

5. Click OK.
6. Click SAVE CHANGES.

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.

Additional Steps

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.

Step 7: Add a process model to your record type as a list action

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.

Add list action

Let's add our reusable interface and process model as a list action.

To add a list action:

1. Open the Employee record type and on the left navigation menu, click List.
2. Under Action, click New Action.
3. In the Display Name field, enter Add New Employee.
4. In the Process Model field, enter Add or Update Employee.
5. In the Visibility field, enter a!isUserMemberOfGroup(loggedinuser(),cons!AT_MANAGERS_GROUP) to set the visibility to managers only.
6. In the Icon field, select the plus icon.
7. Click OK.
8. Under Open Actions In, select DIALOG BOX.
9. SAVE CHANGES to your record type.

Remember that the list action button will appear on your record list page and not on the record views like a related action would.

Congratulations!

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!