No New Elements This Time
This chapter is different. There are no new shapes to learn, no new symbols to memorize.
Instead, we're going to break things - on purpose. Because two of the most common
mistakes in BPMN come from mixing up gateways you already know, and the consequences
are brutal.
Both traps are so common they have their own names: the deadlock and
the multimerge. Both are caused by pairing the wrong opening gateway
with the wrong closing gateway. Before you go any further, make sure you can tell the
exclusive gateway (X) from the parallel gateway (+) at a glance.
## Trap 1: The Deadlock
The deadlock is the trap of getting stuck forever. It happens when you open with an
** exclusive gateway** but close with a parallel gateway.
Remember how these gateways work: the exclusive gateway sends the token down exactly
one path. The parallel gateway, when used as a closing gateway, waits for
tokens from all incoming paths before releasing anything. See the problem?
The exclusive gateway creates one token. The closing parallel gateway sees two incoming
paths and waits for two tokens. The second token was never created. The process waits.
And waits. And waits. Forever.
## Gonzalez Is Still Waiting
Let's go back to the race track. You remember Gonzalez - the impatient Formula One
driver from the previous chapter. His pit stop process originally used a parallel
gateway to split work between the fuel team and the wheel team. Both teams work
simultaneously, tokens merge at the closing parallel gateway, and Gonzalez rockets
back onto the track.
Now imagine someone accidentally replaces the opening parallel gateway with
an exclusive gateway. Everything else stays the same.
The process starts. The exclusive gateway decides: fuel team or wheel team.
Let's say it picks the fuel team. They open the gas cap, refuel the tank, close the
gas cap. Their token rolls to the closing parallel gateway.
And there it stops. The closing parallel gateway sees two incoming paths. It has one
token. It needs two. The wheel team was never activated - their token was never created.
Gonzalez sits in the pit box, engine running, getting angrier by the second.
He will sit there forever. The second token will never arrive because it was never born.
That's a deadlock.
> **Deadlock:** Opening exclusive + closing parallel = process stuck forever. The
exclusive gateway creates one token, but the closing parallel waits for tokens from all paths.
The missing token never arrives.
## Trap 2: The Multimerge
The second trap is the mirror image of the first. Instead of an exclusive gateway opened
and a parallel gateway closed, it's the other way around: you open with a
** parallel gateway** and close with an exclusive gateway.
The parallel gateway does its job - it clones the token and sends copies down every
path. Two paths, two tokens. So far, so good. But the closing exclusive gateway doesn't
merge anything. It simply forwards every token that arrives, independently.
The result? Every task after the closing gateway executes multiple times.
Once for each token that passes through. These are ghost tasks - duplicates that
shouldn't exist but do, because the tokens were never merged back into one.
## Ghost Tasks at the Bookworm Store
Picture a bookstore's order process. A parallel gateway splits the work: one path
prepares the package, another generates the invoice. Both happen at the same time -
that's correct.
But instead of merging the tokens with a parallel gateway, someone places an exclusive
gateway at the merge point. Both tokens arrive at the exclusive gateway. It doesn't
wait for the second one. It doesn't merge them. It just passes each one through.
Now the "ship item" task executes twice. The first token triggers a shipment. The
second token triggers another shipment. Two packages for one order. Two tracking
numbers. Two charges to the shipping company.
You might argue it kind of makes sense - the package and the invoice both
need shipping. But this is a trap, not a feature. Anyone reading the diagram will
almost certainly miss the second token. They'll see "ship item" once and assume it
runs once. The process is technically executable, but its intention is unclear and
misleading.
> **Multimerge:** Opening parallel + closing exclusive = ghost tasks. The parallel
creates multiple tokens, but the closing exclusive forwards each one independently.
Downstream tasks execute multiple times.
## Deadlock vs. Multimerge
Both traps come from the same root cause - mismatched gateways. But their consequences
are very different:
- **Deadlock** is a *technical error*. The process gets stuck and
cannot complete. It must be fixed - there's no working around it. The token is trapped
forever.
- Multimerge is technically correct but practically dangerous. The process runs, but tasks execute more times than intended. It compromises the clarity and expressiveness of your model.
In practice, the multimerge is more insidious. A deadlock is obvious - the process
stops. A multimerge silently creates duplicates that might not be caught until the
process is already running in production, causing real-world damage.
## The Rule
The fix is simple: always pair matching gateways. If you open with an
exclusive gateway, close with an exclusive gateway. If you open with a parallel gateway,
close with a parallel gateway. If you open with an inclusive gateway, close with an
inclusive gateway.
Every time you draw a closing gateway, pause and check: does it match its opening
counterpart? If not, you're setting a trap - either for the process itself, or for
the people who have to read it.
> **The rule:** Always pair matching gateways. Exclusive opens, exclusive closes.
Parallel opens, parallel closes. Inclusive opens, inclusive closes. No mixing.
Remember Gonzalez stuck in the pit box. Remember the ghost shipments at the bookstore.
These are the mistakes that separate careful modelers from everyone else.
This is part of the Learn BPMN series on ProcessCamp - 11 real-world scenarios to master process modeling. Try modeling this yourself in Crismo - free, no signup needed.
Top comments (0)