Process Orchestrator
Transitions
Connect stages, give every exit a condition, and control which path wins with the evaluation order.
A transition connects a stage or gateway to the next element: another stage, a gateway or an end. Transitions that leave a stage always carry a condition, called the Guard. When the stage completes, the process takes exactly one of them: the first one, in Evaluation order, whose condition is true.
This page covers transitions that leave a stage. Transitions that leave a gateway follow the gateway’s rules; see Gateways and ends.
Add a transition
Section titled “Add a transition”- On the canvas, drag from the source stage and drop anywhere on the target card.
- Click the new connector to open the transition panel.
- Enter the Guard: a Yes/No expression that must be true for the process to take this path.
- Optionally, give the transition a title in Docs, such as
Discount over 20%. The connector shows the title instead of the raw condition. - Use Move earlier or Move later to put the transition in the right position.
Settings
Section titled “Settings”| Setting | What it does | Notes |
|---|---|---|
| Evaluation order | Shows the position of this transition among those leaving the same source, as “2 of 3”. | “When more than one condition is true, the first transition in this order is taken.” Change it with Move earlier and Move later. The position also shows on the connector. |
| Guard | The Yes/No condition. | Required on every transition that leaves a stage. It can use process values, the stage’s task or tasks, and the outputs of the stage’s On Exiting flows. Call a decision table or other logic block inside the expression when the rule is complex. |
| Default path | Marks a gateway’s fallback transition. | Only for transitions leaving an exclusive or inclusive gateway. Not available on transitions leaving a stage. |
| Docs | Optional title and description. | The title is shown on the connector. |
How it behaves
Section titled “How it behaves”- Only one transition is taken from a stage. When the stage completes, its transitions are checked in evaluation order and the first one whose condition is true is taken. The others are ignored, even if their conditions are also true. To start several paths at once, lead the stage into a parallel or inclusive gateway.
- No match faults the instance. If none of the conditions is true, the instance is set to Faulted with the message “No business process transition matched.” Nothing is retried.
- Catch-all. To make sure a stage always has a way out, add a last transition whose condition is always true (a Yes/No constant set to Yes) and keep it at the end of the evaluation order.
- Loops are allowed. A transition can lead back to an earlier stage, for example to send a quote back for rework. The earlier stage starts again as a new visit with new tasks.
Transitions have a few structural rules that the designer checks for you:
- A transition cannot lead into an escalation stage; escalation stages are reached only through their parent’s escalation.
- An end has no outgoing transitions.
- A source cannot have two transitions into the same gateway.
Example
Section titled “Example”The Review discount stage on an opportunity has three transitions:
| Order | Title | Guard | Target |
|---|---|---|---|
| 1 of 3 | Rejected | The task’s Decision is Rejected | Notify sales rep |
| 2 of 3 | Large discount | The discount is over 20% | Director approval |
| 3 of 3 | Approved | Always true (Yes) | Prepare quote |
flowchart LR R[Review discount] -->|1: Rejected| N[Notify sales rep] R -->|2: Large discount| D[Director approval] R -->|3: Approved| Q[Prepare quote]
A rejected request always goes to Notify sales rep, even if the discount is also over 20%, because that transition is first. Anything else that is not a large discount falls through to Prepare quote.