Meet Susan
Susan works at Beauty Paradise, a large cosmetics manufacturer. Her job
is customer satisfaction - specifically, she handles requests from customers who want
product samples. A customer calls or emails, Susan checks their loyalty status, picks
the right giveaways, and ships them out.
The problem? It's incredibly repetitive. Every day, the same steps, the same decisions,
the same packaging routine. Susan wants to automate parts of it - but first, she needs to
document exactly how it works. And for that, she needs new BPMN elements you haven't
seen yet.
## When One Choice Doesn't Exclude Another
In the Shoe Shop, Max faced exclusive decisions: the shoes are in stock or they're
not. One path, never both. But Susan's world is different. When she picks giveaways for
a customer, she might send just an eyeliner, just a shower gel,
just a voucher - or any combination of the three.
The exclusive gateway can't handle this. It crosses out all paths except one. What Susan
needs is a gateway that says: "pick any combination."
That's the inclusive gateway. It looks like a diamond with a large
** circle** (or "O") inside. The "O" stands for "or" - not the
exclusive "either/or," but the inclusive kind: this, that, or both, or all three.
> **Inclusive gateway** = diamond with an "O". Unlike the exclusive gateway
(exactly one path), the inclusive gateway activates any combination of paths. The closing
inclusive gateway knows exactly which paths were activated and waits only for those tokens.
## How the Inclusive Gateway Works
When the token hits an inclusive gateway, it can be forwarded down one path, split into
two, or even tripled - depending on which options are selected. Susan checks the
customer's loyalty status (gold, silver, or normal) and decides which giveaways to
include.
The closing inclusive gateway is the smart part. Unlike the parallel
gateway - which always waits for a fixed number of tokens - the closing inclusive gateway
is fully informed about which paths were actually activated. It knows exactly
how many tokens to expect.
Let's walk through a few scenarios:
- **Just the eyeliner:** The opening gateway sends one token down the
eyeliner path. The closing gateway expects exactly one token from that path. It arrives,
and Susan moves on to prepare the package.
- Shower gel and eyeliner: Two tokens are created - one for each path. The closing gateway waits for both before allowing the process to continue.
-
All three giveaways: Three tokens are issued. The closing gateway
expects all three before merging them and passing control forward.## When Expectations Change Mid-Process
Here's where it gets interesting. People often assume the closing inclusive gateway only
receives information from its opening counterpart. That's wrong. The number of expected
tokens can change after the opening gateway has already made its decision.
Consider this: Susan selects only the voucher path. One token is created. But the
voucher branch contains another decision - an exclusive gateway asking
whether to send a physical or digital voucher.
If Susan picks the digital voucher, the token goes to a "send email" task and never
reaches the closing inclusive gateway. The exclusive gateway informs the closing
inclusive gateway: "no token is coming from this direction." The closing gateway
adjusts and doesn't wait for something that will never arrive.
If Susan picks the physical voucher, the token continues as expected, and the closing
inclusive gateway processes it normally.
## Two End Events, Two Outcomes
In Susan's most complex scenario - a gold-status customer getting all three giveaways
with a digital voucher - the process splits into paths that don't all converge. After
the closing inclusive gateway merges the shower gel and eyeliner tokens, two tokens are
still circulating: one heading toward "ship package" and one toward "send email."
This raises a question students always ask: can a process have two end events?
Yes. And here's the important rule: the process doesn't end when the first end
event is reached. It's not a race. Both tokens must arrive at their respective
end events for the process to complete. The customer gets a package and an email.
Why two separate end events instead of one? Because each triggers very different
follow-up activities. Shipping a package involves paying the shipping company and
tracking the delivery. Sending an email does not. The end events make this distinction
explicit.
## Talking to the Outside World
Susan's process doesn't exist in a vacuum. Customers send requests. Susan sends
confirmations. Packages are shipped to real people. These are interactions with
** external parties** - and BPMN has a dedicated element for them:
the message event.
Message events come in four types, each for a different stage and direction:
- **Start message event:** The process begins when a message is received.
Susan's process starts when a customer request arrives via phone or email.
- Throwing intermediate message event: An outgoing message sent during the process - like Susan sending the book and invoice to a customer.
- Catching intermediate message event: A waiting point. The process pauses until a message arrives - like waiting for a customer's payment.
- End message event: The process ends with an outgoing message, like sending a shipping confirmation or payment receipt.
The key distinction: a task describes the action of sending
something. A message event simply states that the message has been
sent - no one is taking action at that moment. Tasks require effort; events mark
that something happened.
> **Message events** mark communication with external parties. They come in four
types: start (process begins on message), catching intermediate (wait for message),
throwing intermediate (send message), and end (process ends with message).
## The Black Box Across the Street
When Susan ships a package, she interacts with a shipping company. When a customer sends
a request, the customer is an external party. We know these interactions happen, but we
don't know - or don't need to know - what the other party does internally.
That's what a collapsed pool represents. It's a pool with no visible
process inside - a black box. You can see that communication happens (via
message flows connecting to the collapsed pool), but not how the external party
processes it.
One important rule: collapsed pools are strictly for external parties.
If you're modeling another department within your own organization, use additional lanes
within the same pool. Using a collapsed pool just because you're unsure what another
department does is not valid BPMN.
> **Collapsed pools** are black boxes for external parties. You see *that* communication
happens, but not how. Use lanes (not collapsed pools) for internal departments.
## Marking Milestones
There's one more element in Susan's toolkit: the plain intermediate event.
You already know the plain start event and the plain end event. The intermediate version
works the same way - a thin double-bordered circle - but it sits in the middle of
your process.
It doesn't influence the process flow at all. The token rolls straight through it. Its
only purpose is to mark a milestone - a significant point in the process
worth highlighting. For example, "Customer Order Fulfilled" marks the moment the order
is considered complete, even though the process continues with shipping and confirmation.
Think of it as a signpost: it doesn't change the road, but it tells you where you are.
## Susan's Upgrade
With her process documented, Susan takes it to the IT department. The diagram speaks
for itself - developers can see exactly what needs automating. The result? Customers
can now select their own free samples through a digital interface. Susan's workload
drops. Customer satisfaction goes up.
That's the power of precise process modeling. The inclusive gateway handles flexible
choices. Message events capture communication with the outside world. Collapsed pools
acknowledge external parties without overcomplicating the diagram. And intermediate
events mark the milestones that matter.
Susan's Beauty Paradise process uses all of these - and now, so can you.
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)