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

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 structure the way that our users will initially 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 be able to filter the records in the list.

3. In the third phase, we will create a way for users to drill into and act upon each record. To do this, we will:

   • Configure the record views so that users can see specific record data.
   • Configure related actions to allow users to update the record that they are viewing.

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.

Requirements

We will be working with many different design objects:

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

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.

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 and a folder to hold our rules and constants.

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 have completed 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 Add Users or Groups and enter AT Administrators.
5. From the Permission Level dropdown list, select Administrator.
6. Click CREATE.

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

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 MORE ABOUT YOUR DATA.
3. From the Source dropdown list, select Data Store Entity, then click NEXT.
4. From the Data Store dropdown list, select the data store that you created during set up.
5. From the Entity dropdown list, select the employee entity you created during setup.
6. Click FINISH.

Phase 2: Configure your 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. 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.

Step 2: 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 column, combine the first and last name columns into one, and add a column for employee title.

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 clicking the red .
   • 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.

Next combine the first and last name columns into one Name column:

1. In the Columns section, delete the lastName column by clicking the red .
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 Component, click Link.
6. Under Link, click Record Link.
7. Click Edit as Expression .
8. Change the label to the concatenated first and last names to show both values within the same field: 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:

1. On the left navigation menu under Grid, click Columns.
2. Click Add Column.
3. Click Grid Column. In the Label field, enter Title.
4. In Sort Field, enter title.
5. To choose the value of Component, click Select Component. Then select Text.
6. Click the Text link.
7. In the Display Value field, enter rf!title.
8. Click OK.

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.

Step 3: Create a department constant

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:

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.

Step 4: Add a user filter

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.

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:

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

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.

Phase 3: Create your record views and actions

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.

Step 5: Create a summary view interface

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.

Create an employee summary interface

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:

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.
6. From the template pane on the right, select CREATE FROM DATA TYPE.
7. In the Data Type field, enter the name of your employee data type.
8. Under Generate an Interface for, select the Displaying Data option.
9. Click GENERATE.
10. Click SAVE CHANGES.

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.

Make rule!AT_getEmployeeById

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:

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.

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.

1. Open your summary view interface and click TEST.
2. In the Test Inputs field's expression editor, 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.

Add summary view to record type

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:

1. Open the Employee record type and on the left navigation menu, click Views.
2. Click the record view called Summary.
3. In the expression editor of your summary view, call in your summary view interface using rule! and the name of your interface in INTERFACE.
4. Inside of the interface rule, call the employee information into the employee parameter of our interface with our expression rule.
5. Inside of the expression rule, call the record ID in the ID parameter with 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)).
6. Click OK.

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.

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 rf!firstName & " " & rf!lastName.
2. Click SAVE CHANGES.

Step 6: 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. 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.

Make a group constant

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:

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 an update employee interface

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:

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.
7. Click TEST.
8. In the Test Inputs expression editor, enter rule!AT_getEmployeeById(1).
9. Click Save as default test values.
10. Click TEST INTERFACE.

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. 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 7: 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 Update Employee.
3. For Save in, select enter AT Process Models.
   • This folder was created in the Application Building Tutorial
4. Click Add Users or Groups and enter AT Administrators.
5. Click CREATE.
6. From the Permission Level dropdown list, select Administrator.
7. Add another group for AT Managers.
8. From the Permission Level dropdwon 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 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:

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. Enter =true to configure the value so that it is true. Your expression will look like: pv!cancel=true.
11. Click Save AND CLOSE.
12. From the Results dropdown list, select Update Canceled.
13. For the Else if none are TRUE condition, select go to the Update Canceled node.
14. 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 Update Employee.
5. In the Context expression editor, your process parameters will automatically display. In the employee parameter, add 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:

1. In the Visibility expression editor, enter isusermemeberofgroup().
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: 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.

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

Step 8: 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 AT_createEditEmployee interface that we set up earlier and create a process model to add new employee records to the employee record type.

Create a process model to add a new employee

Follow these same steps for setting up a process model as you did for the related action:

1. Create a process model named Add New Employee and set security.
2. Add AT_createEditEmployee as the start form and add parameters.
3. Create and configure a cancel flow with an XOR gateway and End Event node.
4. Add and configure the Write to Data Store Entity node.
5. Add activity chaining between the Start Node and the Write to Data Store Entity node.
6. Save & Publish then Start Process for Debugging.

Add list action

Now 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 New Employee.
5. In the Visibility field, enter isusermemberofgroup(loggedinuser(),cons!AT_MANAGERS_GROUP) to set the visibility to managers only.
6. In the Icon field, select the plus icon.
7. Under Open Actions In, select DIALOG BOX.
8. Click OK.
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!