Gateways and branching reference
A process flow branches when one step can lead to more than one path. Process Flows provides three kinds of branching. This topic defines each one and states the effect it has on a run.
Branching types
The following table summarizes the three branching types and when each one takes each path.
| Branching type | How you add it | Paths taken |
|---|---|---|
Exclusive gateway |
A Decision node set to Exclusive. |
Exactly one path. The engine takes the first condition that evaluates to true, in panel order. |
Inclusive gateway |
A Decision node set to Inclusive. |
One or more paths. The engine takes every condition that evaluates to true, and runs those paths concurrently. |
Parallel split |
A parallel split node. |
Every outgoing path, always. Conditions on parallel paths have no effect. |
Exclusive versus inclusive
Both gateway types are configured on the same Decision node. The type you select changes how many paths the process flow can take.
- Exclusive
-
Only the condition that resolves to true is selected, and only its path runs. If two or more conditions resolve to true, the engine takes the first one in panel order, and there is no guarantee which that is when conditions overlap.
- Inclusive
-
Every condition that resolves to true is selected, and each of those paths runs concurrently.
In both types, if no condition resolves to true, the engine takes the default path when one is defined.
The default condition
You can mark one condition as the default with the radio button in the conditions panel. The default path is taken only when no other condition resolves to true.
|
If no default is set and no condition resolves to true, no path is taken and the run fails. The logs record that no condition matched. Set a default condition when a process flow must always continue. |
On an inclusive gateway, the default is a fallback only. It does not run alongside other matched paths. To remove the default designation, select Clear default.
Evaluation order
Conditions are always evaluated top to bottom, in the order they appear in the conditions panel. The order in which you drew the connections on the canvas has no effect. On an exclusive gateway, reordering the rows can therefore change which path wins.
Parallel paths and synchronization
A parallel split activates all of its outgoing paths at the same time, regardless of any data values. To continue only after every parallel path has finished, add a Wait for Branches node where the paths converge.
|
Without a Wait for Branches node, a node that several paths lead into runs once for every incoming path, which causes unintended repeat executions. The canvas shows a warning when this pattern is detected. |
The following table lists the effect of each parallel construct.
| Construct | Effect on the run |
|---|---|
Parallel split |
All outgoing paths start together. If any path fails, the whole run is marked as failed, and the logs record which path failed. |
Wait for Branches |
The next node runs exactly once, after every incoming path has completed. A slower path holds the others until it finishes. |
Data through a decision
A Decision node does not produce its own output. The output that reached the decision is relayed unchanged to whichever node the selected path leads to. For how data moves between steps, see Process Flows.