A tofu company's sales process has a quality check that repeats until the batch passes. Some steps happen in any order. When processes loop and flex, you need markers that say so.
Lea owns Lionis, a small but fast-growing tofu company. She spotted the plant-based trend early, built a loyal customer base, and now she's ready to scale. The plan: hire five new sales representatives and turn leads into loyal customers, week after week.
There's just one problem. Lea can't personally train every new hire. She needs a process that's clear enough for someone like Jen - her first sales rep - to pick up on day one and run with it. No handholding required.
The sales process she sketches out will teach us two powerful BPMN concepts: expanded sub-processes (showing nested work inside the parent flow) and loop markers (repeating work until a condition is met).
You already know sub-processes from the Travel Agency chapter - a rounded rectangle with a small plus sign that hides the detail inside. That's a collapsed sub-process. Clean and compact. Click into it to see what's inside.
But sometimes you wantto see the inside. Lea's sales process has a lead-processing sub-process where events from the parent flow directly affect what happens inside. Hiding that detail would hide the dependencies.
An expanded sub-process solves this. Instead of collapsing the inner process behind a plus sign, it draws the entire sub-process right inside the parent diagram. Same behavior, same token flow - just visible. The sub-process always starts with a plain start event inside its border.
When to use which? Use collapsed sub-processes by default - they keep your diagram clean. Switch to expanded when you need to show dependencies between the parent and sub-process, or when you want to attach events or loop markers to a group of activities.
Here's the full picture. Jen's week starts when all sales leads have been qualified. She runs through two preparation steps:
Then the real work begins: processing each lead, one by one, inside a sequential multi-instance sub-process. The sub-process runs once per lead. When the last lead is processed, the sub-process completes, and Jen creates her weekly opportunity report.
Each lead follows the same flow, but the path through it depends on how the lead responds. After the first email goes out, an event-based gateway waits for one of three things:
Whichever event arrives first determines the path. A positive lead gets a cold call using a predefined sales script. The call itself has three possible outcomes: the prospect wants to buy immediately, wants a sample first, or isn't interested.
If they buy, Jen creates the order, triggers shipment, marks the deal as "won" in the CRM, waits three days, does a follow-up call, and - if the customer is happy - hands them over to account management. That's the happy path.
If they want a sample, Jen sends it, waits three days, follows up with info material and a price list, updates the CRM, waits one more day, and does the follow-up call. From there it's either a handover to account management or marking the deal as lost.
If the lead responded negatively or stayed silent, Jen adapts her sales script accordingly, makes the cold call, and branches from there. A completely uninterested prospect gets a polite info email and a "lost" tag in the CRM.
Lead number four is going well - interested from the start, positive cold call, sample requested. But mid-process, the prospect calls Jen with a special request: "Can you tweak the tofu recipe for us?"
This triggers a non-interrupting conditional event attached to the sub-process. The keyword is non-interrupting - drawn with a dashed border. The original lead processing continues as normal. In parallel, a second path opens up:
Meanwhile, Jen keeps updating the CRM, doing the follow-up call, and handing the customer over to account management. Two paths running in parallel, neither blocking the other. That's the power of non-interrupting events on sub-processes.
Let's step back from Lea's story and look at the concept behind the repetition. Imagine a factory producing heat panels. Each panel goes through the same production step. You could model this with an exclusive gateway that loops back: "All panels produced? No → go back. Yes → continue."
That works, but it's clunky - two extra gateways just to say "repeat." BPMN offers a cleaner solution: the loop marker. A small circular arrow at the bottom of a task or sub-process. It means: "this activity repeats until a condition is met."
The token enters the task, executes it, checks the condition, and either loops back or moves on. Same behavior as the gateway construct, but the diagram stays clean.
Loop markers (circular arrow at the bottom of a task) mean "repeat until done." Three types: simple loop (one at a time), sequential multi-instance (one at a time, fixed count), parallel multi-instance (all at once).
BPMN gives you three loop types, each for a different situation:
The rule of thumb: same input → loop. Different inputs, one at a time → sequential multi-instance. Different inputs, all at once → parallel multi-instance.
There's one more sub-process type Lea uses: the event sub-process. Unlike a regular sub-process that sits in the normal flow, an event sub-process lives inside a parent sub-process and is triggered by an event - not by a sequence flow.
It comes in two flavors:
The key insight: event sub-processes handle exceptions within the scopeof their parent. They're not part of the normal flow - they're contingency plans, sitting quietly until an event triggers them.
Event sub-processes are contingency plans inside a parent sub-process. Interrupting (solid border) cancels the parent. Non-interrupting (dashed border) runs in parallel. They're triggered by events, not by sequence flows.
One last thing Lea teaches us. When you create many process diagrams, naming them well matters. Two approaches:
Both work. Pick the style that makes your process library scannable. The goal is that someone browsing a list of fifty diagrams can find the right one in seconds.
Lea's sales process uses almost every concept we've covered: expanded sub-processes to show the lead processing detail inline, sequential multi-instance markers to repeat it per lead, event-based gatewaysto wait for the lead's response, non-interrupting events to handle ad-hoc requests in parallel, and loop markers to express repetition cleanly.
These aren't academic concepts. They're tools that let Jen - a brand-new hire - pick up a tablet, read the process, and know exactly what to do with every lead, every scenario, every exception. No questions, no guessing. That's what a well-modeled process gives 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 →