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.
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.
Examples of Conditional Branching Tasks in Action
How Conditional Branching works
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.
Parent/child relationships
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.
What happens when Conditional Branching Rules are run
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.
Forwarding User Approvals using Conditional Branching
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.