This tutorial will guide you through the steps to create a process model that end users can start using a record list action.
The process model we're creating in this tutorial will allow users to create new employees in the Employee record type. The form for Employee information contains several inputs that are saved into a process variable so we can use them later.
We'll add a process flow that lets the user cancel their request to add an new employee. For the last step, we'll set up an automatic email to the HR manager letting them know a new employee was added to the system.
If you have a database-backed record type with data sync enabled, Appian can automatically configure your processes for you when you generate a record action.
Let's start by creating the process model object. We'll also use the AT_employeeForm interface as the start form to automatically populate our variables.
To create the process model:
AT Create New Employee.
cancel process variables are created.
You can leave the modeler tab open, because we'll be returning to it in a moment.
Now that we have a process model to build on, we'll configure a new record list action so users have a way to initiate the process.
To create the record list action:
AT Create New Employee.
Now that we have a process model to build on, let's see what happens if we run the record list action in this basic state.
To test out the action:
Click the process instance. The monitoring view of the process instance displays in the Appian Process Modeler. The flow that your process instance followed is highlighted in blue.
In this case, the flow was straightforward: it started at the Start Node and successfully continued to the End Node.
In the toolbar, click Process Details. By default, the Process History tab is active.
In this example, you can see each event Appian logged as you started the record list action, completed the input fields, and submitted the form.
Click the Variables tab. This tab displays the values that Appian populated to the process variables based on your field inputs.
In the PROCESS ACTIVITY list, you might have noticed that the process name is just Create New Employee. As more employees are created and other applications are introduced into this environment, it will become difficult to distinguish processes from each other if the process instance names are generic.
Let's update the name to include information that's specific to each process instance.
To make the process instance names dynamic:
In the Expression Editor dialog:
"New Employee: " & .
& " " &.
This expression adds employee information to the display name of every process instance.
Test the record list action again. This time, in the Monitor view, notice that the process name includes the value from the Expense Item field of the input form:
We've enabled our users to create a new employee, but we still need to handle the case when the user starts to fill out the form, but then wants to cancel the action.
We'll do that by adding a cancel flow to the process.
cancel rule input is part of the two-column form template used for the AT_employeeForm interface. When we chose the interface as the process start form, a corresponding
cancel process variable was automatically created. At this point though, nothing in the workflow uses that variable.
If a user clicks CANCEL,
ri!cancel is set to
true and the AT Create New Employee process is started with
pv!cancel also set to
true. Now, we just need to add a gateway to direct the process flow based on the value of
Gateways let you route the flow to different paths of your process model based on logic you define. In this case, the gateway uses the value of
pv!cancel to select the appropriate workflow path.
To add a gateway node:
Cancel? gateway. A red dot appears indicating that these two nodes will be connected.
Cancel End Event.
The process model should look like this:
Now let's define the logic within the
Cancel? gateway using the
cancel process variable.
To configure the gateway decision logic:
Test the record list action again, but click CANCEL instead of SUBMIT. In the Monitor view, click the process instance to review the process flow. You can see that the process followed the cancel flow.
It's a best practice to formally terminate a process when it reaches an end event node. We'll configure both the End Node and the Cancel End Event to terminate the process on completion of the node action.
In the process model, do the following for each of these nodes:
Click OK. Your end nodes should now look like this:
Each new employee created with the form needs to be saved in the database that backs our Employee record type. The Write Records smart service can take the information stored in the
pv!record variable and add it to the record type's data source.
To configure a Write Records node:
Write Employee Record.
record. The field is automatically populated with the correct process variable syntax.
Let's say the manager of the team using our application wants to be notified by email when new employees are added. We can use a Send E-mail smart service node to meet this requirement. First, we need to get the output of the Write Records node so we can pass the new employee record to the next part of the process.
To store the Write Records output:
For Type, enter
AT and select AT Employee (Record Type) from the list of options.
Now that we have the employee record stored in a process variable, we can set up the email notification.
To configure the Send E-mail node:
toemailaddress() and set your email address as the value (for example,
toemailaddress("firstname.lastname@example.org")). We're manually setting our own email for testing purposes. In a production app, you could select Appian users by entering their names in the To field.
In the Expression Editor dialog:
"New Employee Created: " & .
& " " &.
Our process model now contains a few steps. To initiate the process, we enter the employee information as an action. Then, the process model automatically adds the employee to the database and sends an email. Now it's time to test the whole process.
To test the full workflow:
In the toolbar, click Process Details. The RecordsUpdated variable should include the
id of the new Employee record.
Your process model now collects data for a new employee, saves the data to your record type data source, and alerts the HR manager that the data has been created.
Process Modeling Tutorial