You use transitions, gateways and events to specify the processing order of the actions in a process.
The process builder displays a transition an arrow from a source element to a destination element. The transition specifies that the workflow engine only executes the destination element after completing the source element. BPMN calls a transition a “sequence flow”.
Use an exclusive gateway to make a choice between multiple execution paths. The exclusive gateway selects one of the outgoing transitions, and only continues execution on that transition. You can configure an exclusive gateway with a manual decision or an automatic decision.
Use a manual decision for an exclusive gateway when a person must make a decision. A user task must precede the gateway; this task includes making the decision. The user interface presents the decision to the user as buttons on the user task form.
Suppose you have a user task called “Review contract”, an exclusive gateway and the two user tasks “Print contract” and “Update contract”:
Select the exclusive gateway. Its type defaults to manual decision. After creating the elements and connecting them, as above, you have configured the exclusive gateway:
In order to use the decision you need to name the buttons which will represent the decision. For each button, the label on the right indicates the next action in the process, which Signavio Workflow Accelerator will perform when someone clicks the button. In this example, when the user clicks the decision button “Print contract”, Workflow Accelerator executes the “Print contract” task, but not the “Update contract” task.
You can easily change the text on the buttons, and order they appear in. For example, change them to “Approve” and “Reject”, and drag the “Approve” button configuration to the top so that “Approve” appears first on the form:
After starting a new case for this process, the “Review contract” task will have decision buttons:
When the task before the exclusive gateway - “Review contract” in this example - has a form, the form includes the decision buttons.
Manual decision variable¶
Adding a manual decision to a process also creates a workflow variable. You can use this to re-use the result of a decision later in the process, either to display the entered value on another form, or to use the value in an automatic decision’s condition.
During workflow execution, selecting a decision sets the variable’s value to the selected decision - the text on the decision button. In this example, the decision variable has the value “Approve” or “Reject”.
The variable has the name “Decision”, by default, or the name of the gateway if it has one. You can change the variable name on the process editor’s “Details” tab, in the “Field overview”.
An exclusive gateway that selects an outgoing transition based on conditions that you choose models an automatic decision. For each transition, you can formulate a condition using workflow data. The workflow engine evaluates transition conditions in order, from top to bottom. The workflow engine will take the transition with the first condition that evaluates to true, using the current case’s field values.
To specify a condition, start by selecting a field and a comparison operator. Enter either a static value in the input field on the right, or click the button to select another field.
A condition can include multiple field value comparisons. To add more sub-conditions, click the button at the bottom of the list. You can also use the select field at the top to specify that either all conditions in the list must evaluate to true, or that at least one of them must evaluate to true.
If you do not completely specify a sub-condition, evaluating the whole condition will fail and the workflow engine will not follow the transition. The symbol indicates an incomplete sub-condition, while the symbol indicates a valid sub-condition. Click either of these symbols to remove the sub-condition from the list.
An automatic decision usually has a default transition. You use a default transition as a fallback mechanism: if none of the conditions evaluate to true, the workflow engine follows the default transition.
To make a transition the default, select the “per default” item in the selection field at the top.
Use parallel gateways to model tasks that people will complete at the same time as each other, or one at a time but not in a particular order. To do this, you fork and join the sequence flow.
With a parallel gateway, you can fork execution into multiple, concurrent flows. When process execution arrives in a parallel gateway, the workflow engine creates a new individual execution flow for each of the gateway’s outgoing transitions. Let’s look at the following purchase order example:
In this example, completing the “Enter purchase order” user task activates the parallel gateway. The parallel gateway will create two individual paths of execution. One will take the transition to “Receive payment” and create that user task. Meanwhile, the other will create the “Send goods” user task.
You can have as many outgoing transitions as you want. The workflow engine will create all destination tasks for those transitions at once.
You also use a parallel gateway to join concurrent paths back together. In this case, the joining parallel gateway has more then one incoming transition. Workflow execution will wait at the gateway until as many execution flows arrive as it has incoming transitions. When the last concurrent flow arrives, the joining parallel gateway will activate and the workflow engine will create one execution flow on the outgoing transition.
To continue the previous example, extend the purchase order process to look:
In this example, “Archive purchase order” will only start after people complete both the “Receive payment” and “Send goods” tasks.
By default, the workflow engine interprets multiple outgoing transitions from an action as parallel tasks. This means that if you have multiple transitions from a user task, the workflow engine will create concurrent tasks for all of the transitions’ destination actions. Let’s look at a simple example.
After “Enter purchase order” completes, the workflow engine will create the tasks “Receive payment” and “Send goods” immediately.
You can combine default forking with a parallel gateway for joining.
When multiple transitions lead to a user task, the workflow engine will start the user task once for each execution flow that arrives. This means that the workflow engine does not perform implicit joining for parallel flows.
Parallel gateway issues¶
You will end up with problems if you loop back over parallel gateways. To avoid situations:
To avoid these issues, think of all actions between forking and joining as a self-contained part of the process, such that no transitions should cross that scope.
A start event marks the start of a process. All process elements that do not have incoming transitions act as start elements. Start events don’t have a direct connection to triggers. You can usually leave out start events if you want to create more concise diagrams.
Like start events, you can also omit end events. End events mark the end of an execution flow:
Intermediate timer event¶
An intermediate timer event indicates that process execution waits for a timer. You can use this to prevent Workflow Accelerator creating the next task in a process until it becomes relevant.
Configure how long the timer waits by selecting the timer in the process editor. In an open case, you can skip a timer manually.
A milestone is an intermediate event which allows you to mark an important event or a turning point within a process. By setting milestones, process owners obtain an overview of the workflow progress.
You can set a milestone either by using the intermediate event or via a script task.
Script task sample:
_case.milestone = 'Document archived'
When using the intermediate event, you can reuse any variables from the workflow to create the milestone text by typing
To show the current milestone, add the field “Case/Milestone” as a column in the case list.
Please keep in mind that only the latest milestone is displayed.