Do I need a merging Exclusive Gateway in BPMN?

A merging exclusive gateway (sometimes called an XOR-join or OR-Join) is a BPMN gateway that combines multiple paths into a single outgoing flow. In BPMN terms, it “merges” two or more usually exclusive sequence flows into one.

When you draw one, it looks like a diamond with or without an “X” (just like the exclusive split gateway). By default, however, BPMN does not require an explicit merge for exclusive flows - if two or more branches are truly alternative, the first one to arrive continues the process and the other branches never produce a token.

In other words you can join flows without a gateway.

Different ways of connecting flows in BPMN. All three diagrams show the same logic.

In practice, an exclusive converging gateway has pass-through semantics: it does not wait for tokens on all incoming flows (unlike a parallel join). Only the active branch’s token passes through. Modelers add a merging gateway mainly for clarity and convention, not because it changes execution.

Why some modelers skip merging gateways

Because the converging (merging) gateway doesn’t change the process logic (it’s “transparent”), many modelers skip it to keep diagrams cleaner. 

However, even though it can look tidier, skipping the gateway can have downsides. Without the explicit gateway, it’s not as obvious where branches reconverge.

Why use merging gateways anyway

Even though they’re optional, merging exclusive gateways have several advantages. First, they make diagrams neater and more symmetrical. If you split the flow with an XOR gateway, using another XOR to merge keeps the chart balanced.

Visual symmetry when using gateways in pairs (on the right).

This symmetry isn’t just aesthetic - it signals to readers that the branches match up. This is particularly useful for nested gateways.

Example of a correct diagram without the use of merging gateways.

In this example, the gateways again appear in pairs, creating a symmetrical pattern.

Of course, it is not always necessary to use gateways in pairs. If each branch ends with a separate end event or leads to different results, adding a merging gateway would only be unnecessary clutter.

No need no to use merging exclusive gateways, as different flows have separate ends.

Using the merging exclusive gateway also simplifies later edits. Imagine you built a diagram with several branches that rejoin, and then you realize you need another task right after they meet. If you skipped the gateway, you’d have to reconnect many flows manually to that new task. In contrast, with a merging gateway in place, you simply attach the new task after the gateway.

There is one more trap. If you skip the XOR-join and just draw multiple arrows into an activity, a person experienced with UML activity diagrams may misread this. In UML, multiple incoming flows are interpreted as a join (synchronization) - meaning “wait for all incoming flows” - while in BPMN an implicit reconnection does not synchronize (it’s an uncontrolled merge).

Two visually almost identical diagrams that present completely different logic.

So omitting the BPMN XOR-join can lead UML experts to think the diagram requires all branches to complete, which is not what BPMN does. An explicit XOR-join removes that ambiguity and communicates your intent clearly.

One more important note. In simple cases, all flows coming into a merging exclusive gateway are mutually exclusive - meaning only one branch can ever have a token. But this isn’t always true. If tokens were multiplied earlier (for example, by a parallel gateway) and those tokens are later brought into the same exclusive merge, all of them can pass through. The gateway doesn’t block extra tokens; it just routes each one as it arrives.

Simulation showing the behavior of merging gateways with multiple tokens.

Some people mistakenly believe that only the first token “goes” and the rest are discarded - that’s an error. An exclusive merging doesn’t discard tokens; it simply doesn’t wait for others.

Pros and cons - quick list

If you use merging exclusive gateways

✅ Pros:

• Explicit join point - no guesswork for readers.
• Easier to maintain and extend the model.
• Prevents accidental duplication of tasks.
• Avoids misinterpretation by UML users.

❌ Cons:

• Extra symbol may clutter very simple diagrams.
• Technically redundant when branches truly end separately.

If you don’t use merging XOR gateways

✅ Pros:

• Cleaner, leaner diagrams for small or high-level views.
• Faster to sketch when you’re just mapping ideas.

❌ Cons:

• Can confuse readers unfamiliar with BPMN details (or familiar with UML).
• Harder to add shared steps later - requires rewiring.
• Some modeling tools or reviewers flag “unjoined” flows as style issues.

Summary

In summary, even though merging gateways aren’t mandatory, they improve clarity. They make the process logic explicit, help avoid duplicate tasks, and make future changes easier. The choice of which approach is better is up to you, dear modeler :)