Conditional Branching Tasks
You can use Conditional Branching tasks to define conditional rules for tasks that can test certain conditions and perform actions based on whether or which conditions are met.
Last updated
You can use Conditional Branching tasks to define conditional rules for tasks that can test certain conditions and perform actions based on whether or which conditions are met.
Last updated
Instead of having different templates for each workflow variation, you can create one ‘master’ template with different paths for all the different workflow scenarios. Conditional Branching reduces the total number of separate change requests required to support your workflows; and the number of tasks within a workflow, specifically approval tasks, as these are often used as a method to control workflow branching.
This enables you to create more flexible workflow templates that cover a wide variety of workflow scenarios and business processes, improving workflow management efficiency.
See Also: Creating a Task
Purchase Threshold
An organization has a change workflow template for purchases. Once the purchase information has been entered, an approval for the purchase needs to be made. Most purchase approvals are made by the Finance Manager. However, any purchases over $10,000 need to be approved by the Managing Director of the company.
This is a fairly simple scenario that can be easily implemented using a Conditional Branching task. The first condition, value of the purchase, has two possible branches: one of them leads to an approval by the Finance Manager, the other leads to an approval by the Managing Director. The task has a conditional rule attached to it that checks the value of a field (in this case, the purchase cost) against a number, in this case $10,000. If the field value is less than 10,000, the first approval is activated and the second is closed. If the field value is greater than 10,000, the second approval is activated and the first is closed.
Release Testing Pass/Fail Recursions
An organization is setting up its release workflow. If the build passes all the tests, the release task is run to make the release. If not, the Product Management team has to revisit the business logic after which a series of tasks have to be performed before the software can be released.
To set this up, a Test Build task is created. A Conditional Branching task is used to define two conditional rules. The first condition is specified to state that if the Task Status is set to “Passed”, the release task will be implemented. If the task status is set to “Failed”, the task for assessing the business requirements is implemented.
High Risk and Emergency Changes
An organization has two main change bodies, the Change Advisory Board (CAB) and the Change Emergency Committee (CEC). The CAB is used to review and approve most change requests. However, if a change request has an Urgency value of ‘High’, or has a Risk value of ‘Severe’, the change request must be reviewed and approved by the CEC. In addition, a custom checkbox (‘Post-implementation review’) on the request must be enabled if it is being sent to the CEC.
This is a slightly more complex workflow, using multiple conditions. The first condition has two possible branches: one leading to an approval by the CAB, the other leading to an approval by the CEC. The task has a conditional rule attached to it; this rule checks two conditions, in the following order. If the request has an Urgency value of ‘High’, the CEC workflow path is activated. If the condition is not true, it then checks the Risk value; if it is Severe, the workflow path is also activated. If neither condition is met, the CAB workflow path is activated, and the CEC path is closed off. If the CEC workflow path is activated, the conditional rule also changes the value of Custom Checkbox 1 (‘Post-implementation review’) to 1 (checked).
Additional Actions Based on Any Criterion
An organization has one main national branch and a number of smaller regional branches. Any IT change requests must be implemented by the local branch, and then sent to the national branch for post-implementation review. Whenever a change request is initiated, the necessary tasks must be forwarded to the local regional managers, but the final tasks are forwarded on to the national branch change managers.
This is a fairly complex workflow, with multiple branches. After the initial task (IT Change Request Initiation) is complete, there is a conditional rule with multiple possibilities. The rule tests the value of the Location field on the change request: depending on the value, different task paths are activated. These task paths all end in a task being forwarded to the national branch.
Conditional Branching is based on conditional rules. A rule is a combination of one or more conditions and one or more actions, which results in the implementation of a dependent task. The diagram below shows the logical structure of a conditional rule:
Every conditional rule follows this basic structure:
The action may be something as simple as activating a task or approval (most conditional rules will do this as their action), but they can also change the setting of other tasks and approvals in the same request.
A condition is made up one or more criteria or rules. If all the rules in a condition are true, the condition is true. If any of the rules in a condition are false, the entire condition is false. A condition must always be found to be either true or false.
For Example:
You might have a Task X, with Approval Y and Task Z as dependents. You could have two rules, one for the dependency between Task X and Approval Y, and the other for the dependency between Task X and Task Z. The first rule (between Task X and the Approval Y dependent) states:
IF Request Priority is High AND Request Type is Purchase THEN activate Approval Y (where Approval Y might be a purchasing approval for an accounts manager).
The second rule (between Task X and the Task Z dependent) states the following:
IF Request Type is Software Implementation THEN Activate Task Z AND set Request Risk to Severe, where Task Y might be the beginning of a series of tasks for implementing the software rollout.
This conditional rule contains two conditions (There can be many more). One of these conditions had two criteria that had to be met for the condition to be true. The other condition only had one criterion, but performed two separate actions if the condition was true. All this logic is contained within the one conditional rule attached to the one particular task (or approval).
There is no limit to the number of conditions and actions that a single rule can contain.
It is thus possible to create a complex set of conditional logic attached to one particular task that can activate many different workflow paths within a request. The key advantage here is that you can have one conditional branching task at the beginning of a template that contains multiple conditions; these can route the request to different paths depending on which conditions are met.
Before setting up a Conditional Branching task, it is important to have an understanding of the parent/child relationships in a workflow path.
A parent is defined as a task that has any dependent tasks.
A child is defined as any task that has a parent task on which it is dependent.
A child is dependent on a parent if it can only be activated after one or more conditions for the parent are met.
Some important rules regarding parent/child relationships and Conditional Branching include:
You can only define conditional rules for parents if task-related data from the parent will be used in the conditional branching task. Otherwise, a parent task need not be selected for a conditional branching task.
If a task or approval has no children, it has no dependencies and hence conditional rules are meaningless. You should create all the dependencies for your template or request before defining conditional rules. If the conditional branching task has no dependent task, no actions will be processed.
A parent can only perform actions on its children. When defining conditional rules for a parent, it can only activate or change tasks and approvals that are its immediate children.
Conditional Branching tasks run automatically in a workflow. When a conditional branching task becomes active, it will evaluate the conditions defined on the task and then perform the appropriate action, also defined on the task.
If a conditional branching task becomes active at the same time the request to which it is linked is locked (that is, the request is currently being actioned by the request manager), this task will automatically complete through the workflow polling service, once the request is free. A note will be added to the task history stating that completion of the conditional branching task has been delayed due to the request being locked.
Conditional branching is an alternative way to forward a User Approval task to a variable (such as the user selected on the request), if you have not elected to add the task recipients by using the Other criterion.
You can set up a Conditional Branching task to forward a User Approval task to:
a selected user for approval, using the User Approval Forward action. This action forwards the task to the selected approval user.
the user of the request, using the User Approval Forward user action. This action forwards a task to the request user, if they have approval permissions. If the user is not an approval user, the request history will display an error message to that effect.
the manager of the Request user, that is, the user who has logged the request, using the User Approval Forward to Manager action. The manager is specified in the user’s details in ASM. If a manager has not been specified for the user, the workflow will stop and the user Approval Task will be forwarded to the Request Manager to be appropriately rerouted.
