Process models are incredibly flexible regarding the functionality and workflows you can construct. While the possibilities are endless, there are many common workflows you'll likely need to implement, regardless of the type of application you are building.
This page will highlight some common workflows that are used in many Appian applications today.
You can assign the same task to everyone in a group. There are two things you need to do to achieve this:
To configure a node that spawns multiple instances:
Learn more about multiple node instances.
To assign each task to a different group member:
If a task or process node is delayed for any reason, you can automatically take a number of actions to solve the problem.
Available escalations include:
Escalations can be triggered manually, or by configuring an Escalation Timer Event.
To configure an escalation timer:
On the designer canvas, right-click a node on the designer canvas, then select Escalations. Any existing node escalations are displayed.
Click Add Escalation 
. The Level 1 Escalation options appear. You can add multiple levels of escalation actions.
Under Configure the Timer Event, click Configure to set the timer for the escalation. The Timer Event dialog displays. The timer event has been automatically assigned a name (escalation_timer_#).
(Optional) Change the timer event name.
(Optional) To keep timer events from counting weekends, use the caladddays() function and ensure your process calendar settings exclude weekends from your environment's working hours.
For example, if you want to trigger an escalation four days after the start of the node—excluding weekends—select the Escalate at the date and time… option. Enter the following expression in the text field:
1
=caladddays(now(), 4)
Any non-working days defined in the process calendar are excluded from the escalation timer when the caladddays() function is used.
(Optional) Select the Recurring Timer Escalation checkbox to trigger the event on a repeating schedule, then select from the following options:
| To repeat the task | Select |
|---|---|
| Every n number of days, every weekday, or at a certain time of day. | Daily |
| Every n number of weeks, at a specific time, on a specific day of the week. | Weekly |
| At a certain time, on the nth day of the nth month, or on the nth day of the week (such as the 3rd Sunday) of the nth month | Monthly |
| At a certain time every year: on the nth day of a month, or on the nth day of the week (such as the 3rd Sunday) of the nth month | Yearly |
| Every n number of minutes or n number of hours | At an interval |
To create an escalation timer condition:
In the second field, select the logical operator you wish to use for the condition:
| Operator | Description |
|---|---|
| = | equal to |
| <> | not equal to |
| < | less than |
| > | greater than |
| <= | less than or equal to |
| >= | greater than or equal to |
To escalate by reassigning a task to another user or group:
To escalate by raising or changing the task priority:
Select one of the following options:
| To | Select |
|---|---|
| Raise task priority one level |
|
| Lower task priority one level |
|
| Reset the task priority to High, Normal, or Low. | Change priority and Select High, Normal, or Low from the pull-down list. |
To escalate a task by alerting a user or group:
Press the DOWN ARROW key to select the desired user. — or —
If you want to select more than one user, create a process variable to represent each user. Enter the name of the process variables in the Recipients field separated by commas. For example:
1
={pv!user1,pv!user2,pv!user3}
In the Subject field, modify the message subject to suit your escalation requirements.
The default text is an expression that inserts the task name property &tp!name and the process name &pp!name into the subject. All displayed text is surrounded by quotation marks, and can be directly edited in the Subject field.
Task Escalation Notice text displays.To escalate a task by messaging another process:
See the Send Message Event help topic for more information on configuring a message escalation.
You can execute any activity multiple times in the same process flow by using the Multiple Node Instances (MNI) functionality. Learn more about MNI and other looping designs.
At times, you may need to execute an activity repeatedly by creating a loop in the process flow and route the process flow back to the same activity to execute it again. This type of process activity execution is referred to as a looping process flow.
Learn more about looping types and methods.
You can schedule a recurring execution of the same activity at a given interval. For example, a manager could schedule an activity every Friday at 1:00 PM, which assigns a task to each team member regarding their expenses.
This type of process activity execution is referred to as recurrence.
When activities have been configured to execute on a recurring schedule, it is possible to manually trigger or skip a recurrence.
See also: Scheduling the Start of an Activity
When using multiple node instances to update the values of an array, use the is stored as or the is appended to list operators in your node output.
See also: Custom Node Outputs
If the completion of a task in a process requires the same user to complete a subsequent task, you can activity-chain the two tasks together in your process model. This enables successive form-completion by the same user by chaining the attended tasks together and creating a process wizard (similar to an install wizard).
Note: Long activity chains—greater than 50 node instances or 5 seconds between attended activities—are strongly discouraged because they have both an adverse effect on the performance of the system at scale and the experience of the user.
In order to chain two attended nodes together in a process model, you must enable activity-chaining on their intermediary flow connector.
There are two ways to enable activity-chaining between two attended nodes:
A chain link icon appears on the flow connector between the two nodes to signify they are chained together.
Repeat this action for each intermediary flow between the first and last nodes in your activity-chain.
If you navigate away from the task form in the middle of a chain, all pending tasks are available from your Task Inbox.
When an attended node is chained to another node, by default, the user assigned to the first node overrides the Assignment settings for the next attended node and is automatically assigned to that node as well.
For example, the image below shows lane assignments configured for tasks in the System Administrator and New User lanes. Normally, all attended activities within the lanes are assigned to specific user, group, or set of users and groups. When activity-chaining is enabled, the system assigns any subsequent chained tasks to the person who completed the first task; thereby, assigning the "Upload User Documents" task to the System Administrator once they complete the "Enter User Information" task.
If you want your process to maintain the task assignments, deselect the Override assignment… setting on the Flow Properties dialog.
Once a chain breaks, the next attended task appears in the user's task list (unless it is a Quick Task). To resume the chain, the user must complete the task and then click Next or Continue. Users cannot step back into attended tasks originally part of the chain before it broke.
Activity-chains can break in the following manner:
custom.properties file. See also: Configuring Process Execution PropertiesWhen an activity configured to run multiple instances is part of a chain, any one of the instances is randomly selected as the next node in the chain.
In the example above, a chain is established with Node A, Node B, and Node C. Node A and C are regular tasks, while Node B is configured to run multiple instances—one instance for each assignee.
Upon completion of Node A, any one instance of Node B appears. If three instances of Node B are spawned, any one of those 3 instances may appear as the next task in the chain after Node A has been completed.
Upon completion of Node B, the task for Node C appears. If the Allow users to step back to this node from the next chained activity option is selected on Node A, B, and C, then you can step back and forth between Node A, B, and C any number of times.
If you complete Node A and B and while viewing the task form for Node C, and you step back to B, all information entered in Node B appears on the task form for Node B.
If then you decide to step back from Node B to Node A, all information entered in Node A appears on the task form. In this case, the completed instance of Node B is deleted from the system. When you click Next to move to Node B, a new task form appears. Previously entered data will be lost. If any of the nodes (A, B, or C) do not have the Allow users to step back to this node from the next chained activity checkbox selected, a "Back" button does not appear in the next task form. You are not able to navigate back to the previous task.
This example assumes that the Override assignment for the next attended activity even if the current user is not an assignee flag is enabled in all chained flows.
When an activity that is scheduled to run periodically is part of a chain, the first instance is chained. All subsequent instances are not part of an activity-chain.
Some tasks are part of a process but are not sequential in nature.
A quick task is any attended activity that is activated and completed outside of the fixed process flow. They are initiated on an ad-hoc basis and a new instance of the task is automatically generated after one is completed. All assignees can view and complete the quick task any number of times until the completion or termination of the process.
Any attended process activity can be configured as a quick task. Such activities display the following marker:
Like other tasks, quick tasks are not required to have an incoming flow, but they must have an outgoing flow. If a quick task does not have an incoming flow, it is activated immediately upon startup of the process.
To configure an attended node as a quick task:
In the General tab, select the checkbox next to Quick Task.
When a task is configured as a quick task, the following configuration changes are automatically made:
Any existing forms and data configurations are preserved.
Task assignees can view and complete the task. Apart from the task assignees, process administrators and users with Manager level access to the process can view and complete quick tasks that are assigned to other users and groups.
Activities that cannot be assigned to users do not display the Quick Task checkbox on the General tab of the properties dialog. It also does not appear when viewing a process model in the Process Analyst View.
You can also add a quick task when editing a running process.
Default values in a task form are evaluated when the task is issued. If these values change, the task form is typically updated with the new values when the task is viewed again.
To keep the default values that existed when the task was first issued:
Once a quick task has been activated, you can set it to be disabled if another user attempts to activate it again:
You can configure the quick task so that only the most recent activation of the task is submittable:
Additional execution options are available on the Other Tab.
Once a process has been started, a quick task can be enabled in one of the following ways:
If there are no incoming flows to a quick task, it is enabled as soon as the process is started.
If there is at least one incoming flow, the quick task is enabled once flow reaches it for the first time. Consider a rule event that waits for a condition to become true, or a receive message event that waits for an incoming message; these quick tasks are not enabled until the process flow reaches them.
Once a quick task is enabled, all task assignees can view and complete it. Quick task permissions are evaluated only when the node is first enabled. Permissions are not re-evaluated after each quick task instance is completed; only the initial permissions are used.
An in-flight modification of the assignment of a quick task does not affect currently-enabled quick tasks. It affects only the quick tasks activated after the change.
Once a quick task has been enabled, it can be disabled in one of the following ways:
Attempting to complete a quick task that has been disabled displays the following error message.
This task is no longer available
When a process model has multiple outgoing flows, and activity-chaining enabled on each outgoing flow, any one of the outgoing flows is selected. The next attended task from that flow displays to the user.
In this example, after completing task form A, the task form for either B or C appears at random (depending on assignment configuration). This is not how you should configure multiple outgoing flows.
Rather than configuring a random flow, the standard design practice is to use a gateway to route the flow to either node.
When a node in a process is configured to run multiple instances (or if a process flow loops back on itself) each copy of the node calls and/or writes to the same process variables. In such cases, it is possible to have one instance of a flow overwrite the value in another. To avoid this problem, shield the value passed between each node (in a multi-instance flow) using the Keep process variables synchronized option on the Flow Properties dialog, which is configured by double-clicking the flow connector on your process model.
When the Keep process variables synchronized option is selected, all process variable values used in the output phase of a node are protected from overwrites—from the start of the flow—to the start of the next node. For example, if three instances of a node are spawned (and the node is configured to continue the flow after each instance completes), the process variables in outgoing flows are protected from being overwritten by each other.
The overwrite-protection is distinct for each instance, but it does not place a lock on the process variable (meaning that other flows can still write to the process variable if you have another using the same variables). This feature also triggers an update to the process variable prior to following the flow.
All process variables used during the output phase of a node are shielded from overwrites, when this option is enabled. These include process variables used by expressions in Rules, Timers, and other event conditions.
To protect process variables from overwrites between activities:
When the Keep process variables synchronized option is selected, if a process variable is used in the Output phase of node execution, it is also protected from overwrites across any subsequently shielded flows. The following nodes frequently consume process variables during the Output phase.
Rule Event: When a protected flow arrives at a Rule Event node, the Rule Conditions are evaluated immediately. If the Rule Event is false (and does not execute) the protected process variable value is discarded.
Timer Event: A Timer Event might be triggered during Output; however, if a Timer Event condition is false (and does not execute) the protected process variable value is discarded. A true timer event process variable that is consumed during the Output phase will be shielded from overwrites.
Gateways: When a protected flow arrives at a gateway, the expressions configured for the node are evaluated immediately. The protected process variable value is also retained and made available to any subsequent flows.
Nodes with multiple incoming flows: When processes include gateways with multiple incoming flows with only one outgoing flow, only the process variable values carried by a winning incoming flow are passed on to the subsequent node.
Scheduled Nodes: When a protected flow arrives at scheduled node, the protected value is stored until the node executes.
Receive Message Events: Regardless of the configuration setting, process variables will always synchronize across flows on the output flow for a Receive Message Event node.
Protected process variable values also keep their shielding when associated with a reassigned task. Any subsequent assignees are supplied the same data as the initial assignee.
For any attended activity, keeping process variables synchronized could result in assignees seeing stale data, as there is no inherent limit to how much time a user might take when viewing and completing their tasks.
As the synchronized option only applies to process flows, you might need to write the value from one shielded flow to a Node Input, then to a Node Output, then to the next flow. This would ensure that the process variable value cannot be overwritten during node execution.
Note: If you need to shield more than one flow, we recommend that you put the related nodes into a subprocess.
During the Output phase, a process variable's value is written from the Node Output at the same time it is passed to the outgoing flow. You can further shield the process variable value in other flows by creating a new process variable from the existing value.
To shield a process variable's value through the Start, Run, and Output phases of a node's execution:
ac!, then select the node input you just created from the dropdown list.You can configure any task to capture the geographical location from where the user submits the task. This information can be used for audit purposes to ensure that the task was completed from the right location. This requirement is typical in cases where field workers perform on-site tasks like inspections, maintenance, and repairs.
To capture the location on a task:
On the Forms tab, select the option to 'Capture location on submission(only supported in Appian Mobile)'.
Under Results, select the Submission Location output.
1.In the Result Properties section, click the New process variable icon.
When the user first runs any location-enabled task from the mobile application, a one-time permission prompt displays requesting the user to grant location access to the application. User location is tracked and automatically submitted with the task form only if the user grants permission.
Note: User location is only captured when the task is submitted from Appian Mobile application. To protect user privacy, a banner displays on top of every location-enabled form making it clear to the user that the form is tracking their location.
Once the Home Inspection task form has been submitted by the user, the submission location is stored in the Submission Location result, which we mapped to task_submission_location process variable in step 3.
Next, let's evaluate the distance between the task submission location and the home location using the a!distanceBetween function which evaluates the distance (in meters) between two locations specified by their latitude and longitude coordinates.
Note: The following steps assume you have a process variable named home which has latitude and longitude fields.
To evaluate the distance between the task submission location and the home location:
Add a new Script Task following the Home Inspection task.
Use the following expression to evaluate the distance between the task submission location and the home location.
1
2
3
4
5
6
7
if(
pv!task_submission_location.isAvailable,
a!distanceBetween(pv!task_submission_location.location.latitude, pv!task_submission_location.location.longitude,
pv!home.latitude,pv!home.longitude
),
cons!INVALID_LOCATION
)
In the Target field, save the output of this expression into a new process variable called distance.
iOS and Android Location services do not guarantee that the location delivered is accurate. Rather, a best effort is made, and may be constrained both by the capabilities of the device, the location, and the environment from which it is used. The uncertainty in location is captured in the horizontalAccuracy field of the Submission Location result data. This expresses the uncertainty in the reported location in meters.
You can account for this uncertainty by comparing the evaluated distance to the pv!task_submission_location.horizontalAccuracy value. Generally, you can assume that the task was submitted from the right location if distance < 2 * pv!task_submission_location.horizontalAccuracy. If the distance is larger, you may choose to initiate an audit into that task.
Common Process Model Workflows and Recipes
