Overview

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.

Assigning a Task to Every Member in a Group

You can assign the same task to everyone in a group. There are two things you need to do to achieve this:

• Spawn a separate instance of the task for every member in the group.
• Assign each task to a different group member.

Configuring the node to spawn multiple instances

1. In the Process Modeler, create a task and add it to your process model.
2. Double-click the task node. The Configure Node dialog box is displayed.
3. Select the Other tab.
4. Select the Automatically run multiple instances of this node option.

You can learn more about multiple node instances below.

Assigning each task to a different group member

1. On the Other tab of the Configure [node name] dialog box, click Run one instance for each assignee.
2. Click Run all instances at the same time. This option must be selected, or each task after the first will wait for the prior to complete before being assigned.
3. Select the Assignment tab.
4. Type the name of a group in the Assign to the following field. (You can also enter multiple user names or group names.)
5. Select the There should be one-to-one assignment… option. This option must be selected, or each member of the group will receive multiple copies of the task.

Escalating a Task

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:

• Reassign to another user or group
• Raise or change task priority
• Alert a user or group
• Notify another process

Escalations can be triggered manually, or by configuring an Escalation Timer Event.

Configuring an Escalation Timer

1. Right-click a node on the designer canvas and point to Escalations. Click Escalations). — or —
   In the Configure [node] dialog box, click the Escalations tab. Any existing node Escalations are displayed.

2. Click the Add Escalation button . The Level 1 Escalation options appear. (You can add multiple levels of escalation actions.)

3. Set the timer for the Escalation by clicking the Configure link in the Configure the Timer Event options. The Timer Event dialog box is displayed.

4. The Timer Event has been automatically assigned a name (escalation_timer_#) that you can change if desired. Click the Setup tab. The Configure Timer Event and Timer Conditions group boxes are displayed.
   

   
   

5. In the Configure Timer Event group box, use the Timer Escalation Activation group of options to set a timed delay (either by entering a number or using a logical expression). This option is selected by default. To enter a timed delay, type a number in the field provided (or click the Expression Editor button to use an expression). Select Minute(s), Hour(s), Day(s), or Month(s) from the time-span list.

6. (Optional) To keep timer events from counting weekends, use the caladddays() function. 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. Type 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. (Weekends are specified as non-working days on the process calendar by default.) See Process Calendar Settings.

7. (Optional) Click the Timer Recurrence option to trigger the event on a repeating schedule – by selecting from the following options.

Creating an Escalation Timer Condition

1. In the Timer Conditions group box, click the New Condition button. A row is added to the Event Conditions list, containing three fields to configure.
2. Click the first field and select the process variable you wish to use for comparison.
3. In the second field, select the logical operator you wish to use for the condition.
4. In the third field, type the value you wish to compare against a process variable. If these values match, the condition evaluates as true and the timer event starts.

Escalating by Reassigning a Task to Another User or Group

1. On the Escalations tab of the Configure [Node] dialog box, under the What action should be taken? options, select Reassign task.
2. Click the Directory link next to the Type names field. Locate and select the desired users or groups.

Escalating by Raising or Changing Task Priority

1. Under the What action should be taken options, select Change the priority.
   

   
   

2. Select one of the following options:

Escalating a Task by Alerting a User or Group

1. Under the What action should be taken options, select the Send Alert option. The Alert Message dialog box is displayed.
   

   
   

2. In the Recipients field, begin to type the name of a user to notify. A list of users is displayed.
   

   
   

3. 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. Type name of the process variables in the Recipients field separated by commas. For example:

1
={pv!user1,pv!user2,pv!user3}

1. In the Subject field, modify the message subject to suit your escalation requirements.

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

3. Type the body of your escalation message where the Task Escalation Notice text is displayed.

Escalating a Task by Messaging Another Process

• Under the What action should be taken options, select Send Message Event. The Edit Send Message dialog box is displayed.

See the Send Message Event help topic for more information on configuring a message escalation.

Using Multiple Node Instances in your Process Flows

You can execute any activity multiple times in the same process flow by using the Multiple Node Instances (MNI) functionality.

For example, you might spawn multiple tasks for the same activity when:

• Associating multiple tasks to a single event (such as an interview in a hiring process).
• Recursively building a text document from process data.
• Using Appian RPA to process items from a list.

While using any process nodes other than the subprocess node, the same activity can only be activated up to 1,000 times. Additional instances can be allowed if designated by your server administrator. For more information about configuring the maximum activity instance value, see Post-Install Configurations.

For subprocess nodes, you can run more instances than the configured Maximum Activity Instances Value up to 150,000 instances. This can be helpful if you are using robotic process automation (RPA) and have a robotic task in a subprocess that needs to run more than 1000 times. In these cases, Appian will automatically process the total number of instances in batches of 1000 to efficiently complete the execution of the node. In order to run more than 1000 instances of a subprocess, you will need to configure the Multiple Instances property for the subprocess node.

When multiple instances are configured for an activity, three lines display at the bottom of the node icon.

Multiple activity instances can be executed sequentially or in parallel. Re-execution of an activity creates a new instance, even if the previous instance is not finished processing.

Parallel Execution: All instances are activated simultaneously. They do not have to complete in the same order they were activated.

Sequential Execution: The instances must be completed in the same order that they were activated.

The steps for configuring multiple node instances are listed in the Other Tab of the node's properties dialogue box.

See also: Other Tab

Repeating the Same Task Using a Looping Flow

At times, you may need to execute an activity repeatedly by creating a loop in the process flow and routed 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.

Looping process flows allow you to add information to existing variables and repeat an operation until it is completed.

• If the activity saves data in single value variables, then the data in the variable is overwritten each time the activity is executed.

• If the activity saves data in multiple value variables, you can have the activity attach its output to the end of the existing list of values — OR — You can overwrite a certain value (or record) in a list of values, by specifying its index location.

For details regarding how to append or insert data into an existing variable, see also: Creating a Custom Output

You can configure a looping process flow to spawn based on a definite number of instances or base the number on a process variable.

NOTE: If a process flow reaches a node configured to spawn a number of instances based on an array length or PV of type Number - Integer and the value at the time is empty, null, or zero, the process will pause by exception and throw an error requiring you to resume the process as needed. This type of process flow can be useful when using a subprocess to tabulate report data. When the activity is a subprocess, a new process is started each time the activity is activated.

• Subprocesses use the same execution engine as their parent.

You can determine the number of times that a flow token repeats a loop by placing a gateway in the loop.

• When a looped flow enters an OR or an XOR gateway, the gateway pauses after the first instance token passes through until all other incoming flows arrive.
• Place an empty Script Task activity between the looped flow source(s) and the gateway to remove this restriction.

See also: Gateways and Script Tasks

Running the Same Task Repeatedly on a Schedule

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

Updating an Array

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

Using Activity-Chaining to Display Multiple Forms in Succession

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

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

Enabling Activity-Chaining

In order to chain two attended nodes together in a process model, you must enable activity-chaining on their intermediary flow connector.

To enable activity-chaining between two attended nodes, right-click a flow connector and select Enable Activity-Chaining - OR - Double-click the connector to display the Flow Properties dialog box, and select Yes for the Enable Activity-Chaining option followed by OK.

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.

Activity-chaining is not recommended for use with approval tasks.

If you navigate away from the task form in the middle of a chain, all pending tasks are available from your Task Inbox.

Overriding Task Assignments when Activity-Chaining

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

Breaking a Chain

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:

• If the activity-chain starts with an interface, and the user encounters a form that is not enabled for Tempo.
• A process is paused while an activity-chain is in progress.
• The amount of time between attended tasks exceeds the non-configurable limit of 10 minutes.
• The number of unattended nodes that exists between two (attended) activity-chained tasks surpasses the (default) maximum number of 50.
  • Activating multiple node instances is a common process configuration that may reach this threshold.
  • Adding an attended activity with a simple form that says: Click to continue is one possible way to avoid hitting this limit.
  • Your application administrator can also raise the limit setting in a custom.properties file. See also: Configuring Process Execution Properties
• A user receives a receive message event, rule event, or timer event.
• A user navigates away from an activity-chained form.

Chaining Tasks with Multiple Node Instances Enabled

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

Creating a Quick Task

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

When a task is configured as a Quick Task, the following configuration changes are automatically made:

1. The Refresh default values every time the task form is viewed option is selected on the Other Tab.
2. The option to run the node as an unattended activity is disabled on the Assignment Tab.
3. The Set re-assignment privileges for assignees link is hidden from the Assignment Tab. (Quick tasks cannot be re-assigned.)

Configuring a Task as a Quick Task

To configure an attended node as a Quick Task, right-click the node in the designer canvas and select Properties. The General tab of the dialog that opens provides an option to enable or disable the quick task mode for the activity.

When a task is configured as a quick task, 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 box. 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.

Task Execution Options

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:

• Clear the Refresh default values every time the task form is viewed checkbox on the on the Other tab of the activity's properties.

Once a quick task has been activated, you can set it to be disabled if another user attempts to activate it again.

• Select the do not create if active instances exist checkbox on the Other Tab.

You can configure the quick task so that only the most recent activation of the task is submittable.

• Select delete previously activated instances on the Other Tab. All previously activated instances of the selected task are removed from the system when a new instance is activated.

Additional execution options are available on the Other Tab.

Enabling a Quick Task

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.

Disabling a Quick Task

Once a quick task has been enabled, it can be disabled in one of the following ways:

• Configure an exception flow.
  • When the conditions for this event become true, the exception is triggered, and the Quick Task is disabled.
  • Exception conditions are only evaluated when an activity is first activated.
• Make an in-flight modification to the process, in case no exception flow was configured or you wish to stop the Quick Task manually.

Attempting to complete a quick task that has been disabled displays the following error message.

 This task is no longer available

Configuring Multiple Outgoing Flows

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

• Use an AND Gateway to activate both B and C.
• Use an OR, XOR to activate B or C depending on certain conditions.
• Use a Complex gateway to configure various flow options.

Using Process Variables in Parallel Flows

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 (PVs). 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 box, which is configured by double-clicking the flow connector on your process model.

When the Keep process variables synchronized option is selected, all PV 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 PVs 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 PV if you have another using the same variables). This feature also triggers an update to the PV prior to following the flow.

All PVs used during the output phase of a node are shielded from overwrites, when this option is enabled. These include PVs used by expressions in Rules, Timers, and other event conditions.

Protecting Process Variables from Overwrites Between Activities

1. Double click a Connector between two nodes of the process model. The Flow Properties dialog box is displayed.
   

   
   

2. Select the Keep process variables synchronized across this flow checkbox.

Process Variables and the Output Phase

When the Keep process variables synchronized option is selected, if a PV 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 PVs 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 PV 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 PV value is discarded. A true timer event PV 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 PV value is also retained and made available to any subsequent flows.

Exceptions and Other Considerations

• Nodes with multiple incoming flows: When processes include gateways with multiple incoming flows with only one outgoing flow, only the PV 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, PVs will always synchronize across flows on the output flow for a Receive Message Event node.

Reassigned Tasks

Protected PV 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 PVs 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.

Shielding Process Variables During Node Execution

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 PV value cannot be overwritten during node execution.

During the Output phase, a PV's value is written from the Node Output at the same time it is passed to the outgoing flow. You can further shield the PV value in other flows by creating a new PV from the existing value.

To shield a process variable's value through the Start, Run, and Output phases of a node's execution:

1. Pass the data from a process variable (PV) to a node input.
2. Open the Configure dialog, by double-clicking the node on the Process Modeler Canvas.
3. Select the Data tab.
4. Click the New Input button. A row is added to the Node Input list.
5. In the Type field select the data type that corresponds to the data type that is assigned to the PV.

6. Type an expression in the Value field, using the following syntax.

   1
   =pv!ProcessVariableName
   

7. Save the node input data to a custom node output on the Data tab.
   1. Select the Outputs property sheet on the Data tab of the dialog box.
   2. Click the New Custom Output button.
   3. In the Expression field, select the Expression Editor button. The Expression Editor is displayed.
   4. Expand the Activity Class Parameters in the left navigation of the Expression Editor's Data tab.
   5. Select the name of the node input (created earlier) from the list provided.
   6. Click Save & Close in the Expression Editor.
   7. Save your custom output into the same process variable that supplied the node input data. Select the process variable name from the Target list. Click OK.
8. The outgoing flow(s) must be shielded until the flow no longer executes with multiple instances. Right-click the outgoing flow. Select the Keep process variables synchronized option.

Auditing Task Submission Location

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.

Enabling Location Capture on Tasks

To capture the location on a task:

1. Select the Forms tab from under the task properties.
2. Select the option to 'Capture location on submission(only supported in Appian Mobile)'.
3. Switch to Outputs section under the Data tab. A new result Submission Location of type LocationResult is now available.
4. From under the Results list, select the Submission Location output. From the Result Properties section, click on the New process variable icon.
5. Create a new process variable named task_submission_location of type LocationResult.

Using Task Submission Location

When the user first runs any location-enabled task from the mobile application, a one-time permission prompt is displayed 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.

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 distanceBetween function which evaluates the distance (in meters) between two locations specified by their latitude and longitude coordinates.

1. Add a new Script Task following the Home Inspection task.
2. Switch to the Outputs section under the Data tab and click on the New Custom Output.
3. In the Expression box from under Expression Proeprties, 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
   )
   

4. 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 the that task.