Meet Lea
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).
## Collapsed vs. Expanded: Same Process, Different View
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 want to 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.
## Lea's Sales Process
Here's the full picture. Jen's week starts when all sales leads have been qualified.
She runs through two preparation steps:
- **Score the leads** - using predefined business rules (a business rule task),
she ranks them by potential and stores the list in the CRM.
- Send the first email - a templated introduction goes out to every lead she selected.
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.
## Inside the Lead Processing Loop
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:
- **Positive response** - the lead replies with interest.
- Negative response - the lead replies with a clear "no."
- No response after 3 days - silence.
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.
## When Something Unexpected Happens
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:
- Lea (Jen's manager) reaches out to the customer to clarify the custom product details.
- Lea checks with the production team whether it's feasible.
- If yes, Lea shares the good news and works on a custom deal.
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.
## Loop Markers: Repeat Until Done
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).
## Three Flavors of Repetition
BPMN gives you three loop types, each for a different situation:
- **Loop marker** (circular arrow) - the task repeats with the *same input* each
time. Think of a machine stamping out identical parts. It runs until a count or condition
is satisfied.
- Sequential multi-instance (three vertical lines) - the task repeats with different inputs, one after another. Think of processing payroll: each employee gets a different salary, but they're handled one by one. Jen's lead processing is exactly this - each lead is different, but she works through them sequentially.
- Parallel multi-instance (three horizontal lines) - the task repeats with different inputs, all at the same time. Think of a quality assurance team with multiple microscopes checking all samples simultaneously.
The rule of thumb: same input → loop. Different inputs, one at a time → sequential
multi-instance. Different inputs, all at once → parallel multi-instance.
## Event Sub-Processes: Handling Exceptions
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:
- **Non-interrupting** (dashed start event border) - the parent sub-process keeps
running. Example: a customer asks about their order status. You handle the inquiry in
parallel without stopping the shipment.
- Interrupting (solid start event border) - the parent sub-process is cancelled. Example: a customer cancels their order. The shipment stops, and the cancellation flow takes over.
The key insight: event sub-processes handle exceptions within the scope of 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.
## Naming Your Process
One last thing Lea teaches us. When you create many process diagrams, naming them well
matters. Two approaches:
- **Start-to-end naming:** Look at your ideal start and end events.
Lea's process starts with "Leads qualified" and ideally ends with "Loyal customer won."
Connect them: *Lead to Loyal Customer*.
- Job-to-be-done naming: Simply describe the work: Process Leads.
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.
## The Big Picture
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 gateways** to 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.
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)