Branching, parallel paths, and looping
A process flow controls the order in which its steps run. By default, the steps run one after another, but you can branch into several paths, run paths at the same time, or loop back to an earlier step.
Sequential flow
In the simplest process flow, each step runs after the one before it. The output of each step passes to the next. See How data moves through a process flow.
Branching with a decision
A Decision node sends the process flow down one or more named paths, based on conditions you define:
- Exclusive
-
One path runs, the first condition that resolves to true.
- Inclusive
-
Every condition that resolves to true runs, and those paths run at the same time.
For how conditions are evaluated and what happens when none match, see Gateways and branching reference.
Parallel paths
A parallel split runs several paths at the same time, regardless of any data. Use a Wait for Branches node where the paths converge, so the process flow continues only after every path has finished. Without it, the converging node runs once for every incoming path. See Run branches in parallel.
Looping
A process flow can return to an earlier step. Two patterns are common:
-
A step sends work back for another attempt, such as a rejected task that loops back for amendment and resubmission.
-
A section repeats until a condition is met.
|
The engine has a loop safety limit. If the same loop-back connection is taken 20 times in one execution, the engine treats the run as stuck and stops it automatically. The execution status becomes Stopped, and the stop reason records the loop safety limit. The limit does not tell an intentional long loop from a stuck one. If a process flow loops by design more than about 20 times, redesign it, for example by processing a batch in one step instead of looping once per item. |
A loop safety limit is a safety net, not an exit condition. Always design a loop with its own condition to leave the loop.