This tutorial will help you create your first process model that end users can start as an action. After you have created your process model, you will use this process model to create a record type with your process model as its source. This tutorial is dependent on the completion of the Interface Tutorial, which created the form needed to complete this tutorial. You will need to be a member of the Process Model Creators group. Contact your system administrator if you are unsure if you belong to this group.
We will start with a simple form where users can input information. Additionally, we will add an approval step for a supervisor to approve the submitted information.
Use the examples provided to understand how to set it up. Then, try it with your own data.
The process model we're creating in this tutorial is for a simple expense management application. We’ll create an action so that users can submit their own expense reports and a record type for users to view the expense report. The form for the expense report will contain a few inputs that are saved into process variables so we can report on them later. Next, we'll add a process flow for if the user cancels their request. For the last step of setting up your process model, we'll add an approval step for a user to approve the expense report submitted. Once your process model is complete, we'll quickly walk through how to create an expense reports record type with your process model as its source.
Let's start by using the expenseReportForm
interface to create an application action. To do this:
Submit Expense Report
in Action Name.Expense Mgmt Example
in Folder Name.Expense Mgmt Example
in the Folder field, then select your new folder from the suggestions.You have just created a process model for submitting expense reports and made it available in Tempo as an action. This feature essentially does the following:
To test it out, open Tempo and click the Actions tab. You should see Submit Expense Report in the list. You will also notice the Appian Tutorial application added to the left-side of the navigation pane.
Click Submit Expense Report to test it out. You should see the following:
Complete and submit the form.
You can see your process by selecting the Monitoring view in Appian Designer or in the Application view.
Notice that the process name is simply Submit Expense Report. As more expense reports are submitted and other application are introduced into this environment, it will become difficult to distinguish processes from each other.
So, let's update the name to include more information about the process instance. To do this:
="Expenses Submitted: " & pv!expenseItem
in Process Display Name. This adds expense item information to the display name of every process instance.Now let's add a cancel flow to the process for when the user clicks Cancel.
We already have all our process variables set up for us. Now we need to add a gateway to redirect the process flow if the user clicks cancel.
Start Node
and End Node
and drop it on top of the existing connector when the connector turns blue. This indicates that you can add the object to the existing flow.Cancel?
.Cancel?
gateway. A red dot appears indicating that these two nodes will be connected.End Event
node. The two nodes are now connected.Cancel End Event
.Cancel?
node. Add a label of No for the End Node
outflow and Yes for the Cancel End Event
outflow.The process model should look like this:
Now let's configure the logic within the Cancel?
gateway.
Cancel?
node.pv!cancel
in the expression field.To test it out, submit the action in Tempo by clicking the Cancel button.
Next, let’s add an approval step to the process model and assign it to the process initiator's supervisor. In the approval task, we'll use the same form that the user fills in when starting the process, but we'll mark each input as read-only. We'll also show a radio button where the approver will select whether the expense report should be approved or rejected. In the Interface Tutorial, we configured the interface to already include this behavior, so we just need to reuse that form here.
Let's add the approval task to our process model:
Approve Expense
="Approve Expenses for " & user(pp!initiator,"firstName") & " " & user(pp!initiator,"lastName")
expenseReportForm
The forms tab should look like this:
Next, we need to configure the activity class parameters created by importing the rule inputs:
Name | Value | Save into | Notes |
---|---|---|---|
expenseItem | pv!expenseItem | no value | The item name will be display as a read only field. The Approver will not be changing this value, so we don't need to save into any process variable. |
expenseDate | pv!expenseDate | no value | The expense date will be display as a read-only field. The Approver will not be changing this value, so we don't need to save into any process variable. |
expenseAmount | pv!expenseAmount | no value | The expense amount will be display as a read-only field. The Approver will not be changing this value, so we don't need to save into any process variable. |
cancel | no value | no value | Cancel will not be used on this form. Leaving the value and save into fields blank with effectively ignore this activity class parameter |
comments | pv!comments | no value | The comments will be display as a read-only field.,The Approver will not be changing this value, so we don't need to save into any process variable. |
step | APPROVAL | no value | Setting this activity class parameter's value to "APPROVAL" tells the reusable expenseReportForm to display the appropriate fields |
approve | no value | pv!approve | Since approval will be decided at this step, we do not need to provide a default value. However, we do need to save into a process variable if we want to use this value later. |
Finally, select a task assignee:
Process Initiator
and then select it from the auto-complete list displayed.
Our process model now contains two steps: one to enter the expenses information as an action, and one to approve the expenses. You can test it out just as you did earlier from the Actions tab by clicking Submit Your Expenses. After submitting the expenses form, click the Tasks tab to view the approval task, and you should see the following:
Your process model now collects data from users on two forms, allows users to choose from one of two buttons when submitting the form, and validates the number of characters a user adds to the comments field.
All the data each user enters is available for viewing and reporting by accessing the process variables you configured.
As mentioned earlier, by using an interface, you can configure a multitude of other validations, components, and dynamic behavior. To do so, you simply need to update your expenseReportForm interface.
See Also: Interface Recipes to create different interfaces with specific layouts and dynamic behavior
Now that you have the Submit Expenses process model completed, we'll be using it to create a record type of expense reports.
To create the record type:
Expense Report
. In Plural Name, Expense Reports
will auto-populate.List of expense reports
.AT_Administrators
, and select Administrator.After the Expense Report record type opens, we need to choose our data source.
To select a source:
Submit Expense Report
to choose your process model.To configure the record list:
1
2
3
a!listViewItem(
title: rv!record[recordType!Expense Report.fields.expenseItem]
)
expenseDate
.Now we're going to create a summary view interface for our record type. This view will display the information of each expense report record.
To create a summary view:
expenseReportSummary
.1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
{
a!textField(
label: "Requester",
labelPosition: "ADJACENT",
value: user(ri!expenseReport[recordType!Expense Report.fields.pp.initiator], "firstName") & " " & user(ri!expenseReport[recordType!Expense Report.fields.pp.initiator], "lastName"),
readOnly: true
),
a!textField(
label: "Amount",
labelPosition: "ADJACENT",
value: ri!expenseReport[recordType!Expense Report.fields.amount],
readOnly: true
),
a!textField(
label: "Date",
labelPosition: "ADJACENT",
value: ri!expenseReport[recordType!Expense Report.fields.date],
readOnly: true
)
}
expenseReport
.You will be unable to view the interface right now because the null value for the user function shows as an error. Don't worry, you set it up correctly! You'll be able to see the summary view once it is added to the record type.
With the view's interface created, it's time to add the interface to the record type as a summary view.
To add a summary view to the record type:
rule!expenseReportSummary()
.expenseReport:
.rv!record
to call each records' data into the rule input.
rule!expenseSumarryView(expenseReport:rv!record)
You have just created a record for each process instance of the Submit Expenses process model.
If you go the record list view in Tempo, you might not see any expense reports listed. This is because you currently don't have any instances of the process. Let's add one and take a look at the result.
Start an instance of the Submit Expenses process with the following values:
Plane ticket to St. Louis
.200
.4/16/2013
.Flights are expensive
.In Tempo, select the Records tab, and click Expense Reports.
You should see the following:
Select the "Plane ticket to St. Louis" record.
You should see the following:
In the summary view interface, you'll notice that we used record type field reference to access process variables. For record types with process models as their source, you can access process variables, process properties, and process model properties as record fields using record type field references.
Only certain process and process model properties are available for use in interfaces. Besides that, you can change this record view design as you would any other interface.
For more information on referencing process and process model properties, see Referencing record fields and field values.
When working with record types that use a process as their source, you are able to create quick tasks and use them as related actions in your record type.
If the process model you used as the source for the record had quick tasks, the available quick tasks would automatically appear in the list of related actions for those records. Quick tasks only appear in this list and can't be used as related action shortcuts on record views.