A cosmetics company is going digital. Customers can pick multiple treatments, and suppliers need to be coordinated. When one choice doesn't exclude another, you need a different kind of gateway.
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.
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.
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:
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.
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.
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:
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).
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.
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.
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.
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 →