Two modeling mistakes that break every beginner's process. One freezes the process forever. The other creates ghost tasks that shouldn't exist. Learn to spot them before they cost you.
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.
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.
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.
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.
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.
Both traps come from the same root cause - mismatched gateways. But their consequences are very different:
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 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.
Interactive diagram coming soon
This will be a live Crismo canvas you can explore and edit
Model this process yourself
Open a free diagram in Crismo and build what you just learned. No signup needed.
Open in Crismo →