In BPMN 2.0, how do exclusive, inclusive and parallel gateways behave when they split the flow and when they join it?
answer
- X, O and plus markers
- one, some or all branches
- conditions in order or all evaluated
- pass through, wait for expected, wait for all
basics
~20 sIn BPMN 2.0 an exclusive gateway takes exactly one branch and merges without waiting; an inclusive gateway takes every branch whose condition is true and joins those still expected; a parallel gateway takes all branches and waits for all.
solid answer
~50 sOn a **split**: an **exclusive** gateway (optional `X` marker) evaluates its conditions in order and sends the token down the **first** true branch, or the default flow if none is true; an **inclusive** gateway (`O`) evaluates **all** conditions and sends a token down **every** true branch, again with a default; a **parallel** gateway (`+`) evaluates nothing and sends a token down **every** branch. If no condition is true and there is no default, the exclusive and inclusive gateways throw an exception. On a **join**: the exclusive gateway passes each arriving token straight through with **no synchronisation**; the parallel gateway waits for **a token on every** incoming flow; the inclusive gateway waits for tokens on the branches that were actually started and could still arrive. In a claim process: fraud flagged or not is exclusive; medical and police reports both required is parallel; "medical if injured, police if stolen" is inclusive.
go deeper
Recall the markers X, O and plus, and whether each takes one, some or all branches when splitting.
Explain condition evaluation order, default flows and exceptions, and what each gateway waits for when joining.
Match every split with the join of the same semantics, and use defaults so data outside the expected cases cannot stop an instance.
Set modelling rules for gateway use, such as matched pairs and mandatory defaults, so large process libraries stay analysable and executable.
## Gateways control flow, not work In BPMN 2.0 (OMG formal/13-12-09) a **gateway** is a diamond that controls how sequence flows **diverge** (split) and **converge** (join). It represents no work and takes no time; it only decides how many tokens continue and where. A gateway must either split or merge: it needs more than one incoming or more than one outgoing sequence flow. Its marker names the type. ## The three core types side by side | | Exclusive (XOR) | Inclusive (OR) | Parallel (AND) | |---|---|---|---| | Marker | `X`, optional (but used consistently in a diagram) | circle `O` | plus `+` | | Split: branches taken | exactly one | one or more (every true condition) | all | | Split: conditions | evaluated **in order**, first true wins | **all** evaluated, in no particular order | none | | Split: nothing true | default flow; exception if no default | default flow; exception if no default | not applicable | | Join: waits for | nothing: each token passes straight through | the tokens that can still arrive | a token on **every** incoming flow | | Can throw an exception | yes | yes | no | ## Exclusive gateway A diverging exclusive gateway is a question with alternative answers: "is the claim flagged as possibly fraudulent?" The execution semantics are precise: conditions are evaluated **in order**, the **first** one that is true receives the token, and no further conditions are evaluated. Only if none is true does the **default** flow get the token; with no default, an exception is thrown. A converging exclusive gateway is a **merge without synchronisation**: every token that arrives is passed on. That is correct when the incoming branches are alternatives, since only one of them ever carries a token. ## Parallel gateway A diverging parallel gateway **forks**: every outgoing flow receives a token and no conditions are checked. A converging parallel gateway **joins**: it is activated only when there is **at least one token on each incoming flow**, and then it consumes **exactly one** token from each and produces one on each outgoing flow. Extra tokens on an incoming flow stay there for the next activation. In the insurance-claim process, a large motor claim needs both a medical report and a police report. A parallel split starts "Obtain medical report" and "Obtain police report" together; a parallel join waits for both before "Assess liability". ## Inclusive gateway A diverging inclusive gateway evaluates **every** condition, and **each** true one gets a token: zero, one or all branches could in principle be taken, so the model should guarantee at least one, usually with a default flow. For example: 1. "Claimant injured" is true, so "Obtain medical report" starts. 2. "Vehicle stolen or collision reported" is false, so no police report is requested. 3. Neither true would take the default flow, "Standard assessment". The converging inclusive gateway must **synchronise the branches that were started**, without waiting for ones that were not. That is its defining difficulty, and it is covered in its own question. ## Choosing the right one - The answer is one of several alternatives: **exclusive**. - Everything must happen, and all must finish before continuing: **parallel**. - Some subset must happen, decided by data, and all the chosen ones must finish: **inclusive**. - The choice depends on *which event happens first* rather than on data: an **event-based** gateway, not an exclusive one. ## Mistakes interviewers look for - Believing an exclusive gateway evaluates all conditions and picks the "best" one; it takes the first true one in order. - Believing a parallel split can be conditional; it has no conditions. - Joining alternatives with a parallel gateway, or parallel branches with an exclusive one (the mismatch problem). - Forgetting the **default** flow, so that a claim matching no condition stops the process with an exception. - Mixing gateways with and without the `X` marker in one diagram, which the specification says should not happen.
- In BPMN 2.0, what happens at a diverging exclusive gateway when two conditions are true at once?Only one branch is taken: the conditions are evaluated in order and the first true one receives the token; the rest are not evaluated. If overlapping conditions are intended to start several branches, the gateway should be inclusive.
- In BPMN 2.0, what happens if no outgoing condition of an exclusive or inclusive gateway is true and there is no default flow?The gateway throws an exception at run time. A default flow, which receives the token only when no condition is true, avoids this; its own condition, if any, is ignored.
An exclusive gateway is a single-lane fork in the road; a parallel gateway is a relay team setting off together and regrouping only when every runner is back; an inclusive gateway is a manager who sends just the specialists a case needs and waits for exactly those.
saying these in an interview costs you the question
- An exclusive gateway evaluates every condition and picks the best match.
- A parallel gateway only starts branches whose conditions are true.
- An exclusive merge waits until all incoming branches have arrived.
- A parallel join continues as soon as the first branch arrives.
- An inclusive gateway always takes at least one branch without a default flow.