Gateways and ends

Gateways let a process do more than move from one stage to the next. Use them to choose between paths, to run several stages at the same time, and to wait for branches to come back together. End nodes mark where a path finishes. Every stage needs an outgoing transition, and every process needs at least one End.

Gateway kinds

Kind	Shape	When it splits	When it merges
Exclusive (XOR)	Diamond with X	Takes the first transition whose condition is true, in evaluation order, or the default one. Exactly one path.	Every arriving branch passes straight through. It does not wait.
Parallel (AND)	Diamond with +	Takes every outgoing transition at the same time. Its transitions have no conditions.	Waits until a branch has arrived from every incoming transition.
Inclusive (OR)	Diamond with O	Takes every transition whose condition is true, or the default one when none is.	Waits for every branch that can still reach it.

A gateway’s role comes from how you connect it. With one incoming and several outgoing transitions it splits; with several incoming and one outgoing it merges; with several of both it does both. The gateway panel shows the count, for example “2 incoming, 3 outgoing transitions.” A gateway that neither splits nor merges is a problem, because it does nothing.

Add a gateway

1. Select the stage or gateway the new gateway should follow.
2. Select Add, then under Gateways choose Exclusive (XOR), Parallel (AND) or Inclusive (OR).
3. Connect the gateway to the next elements by dragging from it and dropping on each target card.
4. For an exclusive or inclusive gateway, click each outgoing connector and set its Guard, or switch Default path to On for the fallback path.
5. To change the kind later, click the gateway and change Kind.

Conditions and the default path

• Each transition leaving an exclusive or inclusive gateway needs a condition, or must be the gateway’s default path.
• Default path is “Taken when no other transition leaving the gateway has a true condition.” A gateway can have only one default path, and the default path has no condition. The connector shows Default.
• Transitions leaving a parallel gateway are always taken. They have no condition and no default; the connector shows Always.
• All conditions are evaluated before any branch starts. Starting one branch cannot change whether another branch’s condition is true.
• If no condition is true and there is no default path, the instance faults with “No transition leaving gateway X matched.” Add a default path to exclusive and inclusive gateways to avoid this.

Values a gateway condition can use

A gateway condition can use the values of the transitions that lead into it:

Gateway	Values available to its outgoing conditions
One incoming transition	Everything its source can see. After a stage: the completion values, the task or tasks and the On Exiting flow outputs. After another gateway: what that gateway sees.
Exclusive, several incoming transitions	Only the values that all incoming paths share, with the same type.
Parallel or Inclusive merge	Only process instance values.

If you rewire a gateway, its existing conditions are kept, and the problems list reports any value the conditions use that is not available on the new path.

Ends

An End (Add > Events > End) is “Where a path of the process finishes.” Each End needs at least one incoming transition and cannot have outgoing transitions. Give Ends meaningful names in Docs, such as Quote sent or Request rejected, so the outcome is clear in the viewer.

• A process needs at least one End. You can have as many as you like.
• Reaching an End finishes that path only. Other branches that are still running carry on.
• The instance is completed when no branch is left open. In the viewer, the End turns green when the instance completes.

How parallel branches behave

• After a parallel or inclusive split, the instance has several active stages at once, one per branch. Each branch has its own tasks and its own values, so values set in one branch do not leak into another.
• Branches of the same instance move on one at a time. While one branch completes a stage (its On Exiting flows, routing and the next stages’ On Entering flows), the instance’s other branches wait. Keep stage flows short in processes with parallel branches.
• An inclusive merge waits for every branch that can still arrive, and it counts escalations too: if a waiting branch could still escalate to a stage that leads to the merge, the merge keeps waiting.
• If the only branches left are waiting at merges that can never be satisfied, the instance faults with “The business process cannot go on: gateway X waits for branches that can no longer arrive.” The classic cause is a parallel merge fed by an exclusive split: only one branch ever arrives, but the merge waits for all of them.
• In the viewer, a merge that is still waiting shows “Waiting for other branches”.

Examples

Choose one path (exclusive)

A case is routed by priority. The default path catches everything that is not high or low priority.

flowchart TD
  T[Triage case] --> G{X}
  G -->|High| E[Escalate to tier 2]
  G -->|Low| S[Self-service reply]
  G -->|Default| N[Standard handling]
  E --> R((Resolved))
  S --> R
  N --> R

The exclusive gateway does not need a matching merge: each path leads to the End on its own.

Do work in parallel (parallel split and merge)

When an order is confirmed, finance and logistics work at the same time, and the customer is notified only when both are done.

flowchart TD
  C[Confirm order] --> P1{+}
  P1 --> I[Issue invoice]
  P1 --> S[Ship goods]
  I --> P2{+}
  S --> P2
  P2 --> N[Notify customer]
  N --> E((Order complete))

Optional reviews (inclusive split and merge)

A quote may need a legal review, a finance review, both or neither. The inclusive merge waits only for the reviews that were started.

flowchart TD
  Q[Draft quote] --> O1{O}
  O1 -->|Non-standard terms| L[Legal review]
  O1 -->|Discount over 15%| F[Finance review]
  O1 -->|Default| O2{O}
  L --> O2
  F --> O2
  O2 --> S[Send quote]
  S --> E((Quote sent))

Avoid: parallel merge after an exclusive split

flowchart TD
  A[Assess] --> X{X}
  X -->|Approve| B[Approve]
  X -->|Reject| C[Reject]
  B --> P{+}
  C --> P
  P --> E((End))

Only one branch leaves the exclusive gateway, so the parallel merge waits for a branch that can never arrive and the instance faults. Use an exclusive merge here, or connect each branch to its own End.

Related

• Transitions
• Instances
• Validation messages
• Best practices