Forem: Crismo Team

Lionis: Loops and Ad-Hoc Sub-Processes in BPMN

Crismo Team — Wed, 08 Apr 2026 13:18:12 +0000

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&apos;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&apos;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&apos;s process starts with &quot;Leads qualified&quot; and ideally ends with &quot;Loyal customer won.&quot;
      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.

Fastfore: All 7 BPMN Task Types Explained

Crismo Team — Wed, 08 Apr 2026 13:17:36 +0000

Meet Jessica

Fastfore is a fast-growing consulting company, and growth means one thing above all
else: hiring. Applications are flooding in - dozens every week - and
the process to handle them is pure chaos. CVs get lost in inboxes, interviews are
scheduled over each other, and rejection emails go out three weeks too late.

Jessica, the head of HR, has had enough. She wants an automated workflow that
handles applications from start to finish. But before anyone writes a line of code,
she needs to understand the process - and communicate it clearly to the engineering
team who will build it.

So Jessica draws a BPMN diagram. And because she's designing a process that will
be automated, she uses something beyond the generic task boxes you've seen so far.
She uses task types - seven specific variants that tell you not just
what needs to happen, but how it happens.

  ## Beyond the Generic Task

Every task you've drawn until now has been a plain rounded rectangle - the generic
task. It works for any job. But when you're preparing a process for automation,
"any job" isn't specific enough. The engineering team needs to know: Is this
done by a person in software? By a person with their hands? By a machine? By a script?

BPMN solves this with a small icon in the upper-left corner of the task.
That icon identifies the task type. Seven types, seven icons, seven ways work gets done.
Let's meet them all through Jessica's hiring process - and then see them again
on the factory floor.

  ## The Hiring Process: Happy Path

An application arrives. The first thing HR does is screen the CV and the cover letter.
Jessica's team does this in their HR software - they open a form, review the
documents, and click Accept or Reject.

That's a user task. A person performs the work inside an IT system,
typically by filling out or submitting a form. The icon is a small person with a
monitor. Whenever you see someone working in software - entering data in SAP,
reviewing a case in a CRM, approving a request in a portal - that's a user task.

If the applicant looks promising, the department manager gets notified to review the
profile. That notification is an automated email - no human writes it, no human clicks
Send. The system fires it automatically.

That's a service task. It represents work done entirely by a machine -
calling a web service, triggering an API, executing an automated operation. The icon is
a small gear. No human involvement, pure automation.

  ## Scheduling and Interviewing

The department manager reviews the profile (another user task - same
pattern: person in software, form, decision buttons). If they approve, HR needs to
schedule an interview.

Now here's a question: how does the interview get scheduled? In Jessica's
current process, someone manually scrolls through calendars trying to find a free
slot for both the HR manager and the department manager. That's tedious - but
it's the reality right now.

Once the interview is scheduled, HR sends the invite to the candidate. This is an
explicit act of communication - a person prepares a message and dispatches it. That's
a send task. The icon is a filled envelope. It represents someone (or
something) actively transmitting a message, a document, or a package to a defined recipient.

Quick note: you can model the exact same thing with a generic task followed by a
throwing message event. Both mean the same thing in BPMN. Use the send task when
you're already using task types throughout your process - it keeps things consistent.

After the invite goes out, the process waits. It can't proceed until the candidate
responds. That waiting - actively receiving something from the outside - is a receive
task. The icon is an empty envelope. The key difference from a catching message
event: the receive task implies someone actively receives the response (think
of someone walking to the mailroom and picking up a package), while a catching event
is more passive (an invoice lands in your inbox without you doing anything).

  ## The Interview Itself

The candidate shows up. The HR manager and the department manager sit across the table,
ask questions, evaluate body language, take notes on paper. No software involved. No
screens. Just people talking.

That's a manual task. The icon is a small hand. It represents work
done entirely without IT system interaction - packaging a shipment, conducting a
physical inspection, having a face-to-face meeting.

After the interview, the team evaluates the candidate. They decide: hire or reject.
This evaluation follows strict criteria - minimum years of experience, required
certifications, salary band rules. These aren't gut feelings; they're
documented business rules.

That's a business rule task. The icon is a small table. This task
applies pre-defined rules to reach a decision - a bank checking your creditworthiness
against income thresholds, a quality team verifying samples against compliance norms,
or HR matching a candidate against hiring criteria. Business rule tasks can even be
linked to a formal decision model (DMN - Decision Model and Notation), where the
rules are executed automatically.

  ## The Offer or the Rejection

If the candidate passes, HR sends the offer - a send task. If they
don't pass, HR sends a rejection email - a service task (automated,
no human writes it). Three different outcomes in the process, three different paths,
but every task is now explicitly typed.

And that's Jessica's hiring process. But there's one task type we
haven't seen yet.

  ## The Missing Type: Script Task

Fastfore's hiring process includes a custom assessment: a coding challenge for
engineering candidates. The challenge is evaluated by a script - a small program that
runs the candidate's code against test cases and produces a score.

That's a script task. The icon is a small scroll. Unlike the
service task (which calls an existing external service), the script task
executes a custom script directly in a runtime environment. You wrote the
logic yourself, and it runs right there.

The distinction matters for engineers:

  - **Service task:** You call something that already exists - a Google
      Calendar API, a payment gateway, an email service. You leverage an external capability.

Script task: You wrote the code yourself and execute it directly.
A Python script that calculates salary bands based on experience, a scoring algorithm,
a data transformation.

## On the Factory Floor

Fastfore isn't just a consulting firm. One of their largest clients is Space
Z, a spacecraft manufacturer. Let's see the same seven task types in action
on their production line - because task types really shine when physical and digital
work coexist.

The process starts with checking material availability. The planning team looks this up
in their ERP system - a user task. They're in software, querying
a database, reading results on screen.

If parts are missing, they send a purchase order to the supplier - a send task.
When the goods arrive, a warehouse worker physically receives them - a receive
task (someone actively takes delivery, not a passive inbox event).

But what if the supplier doesn't deliver within three days? Someone gets in a car,
drives to the supplier, and picks up the parts manually. That's a manual
task - no IT system involved, just a person and a vehicle.

  ## Planning and Production

Once materials are ready, the planning team creates the production plan in their planning
software - a user task. But the software doesn't cover everything.
The team has built their own script to calculate sample sizes outside the official tool.
That calculation is a script task.

The quality assurance team reviews the plan against pre-defined norms. If the sample
size is below 5% of the production batch, they reject the plan. These are strict,
documented rules - a business rule task.

With the plan approved, the production team adjusts the machines. Workers turn dials,
swap tooling, calibrate equipment. Some machines have interfaces, but the bulk of
the work is physical - a manual task.

Then the machines run. They produce the samples automatically - a service
task. The machines are the service. They were configured, started, and now
they do the work without human intervention.

Finally, quality assurance inspects the samples against compliance norms - another
business rule task. Clear criteria, documented thresholds, pass or fail.

  ## The Golden Rule

Here's the most important principle for choosing task types: when in doubt,
pick the less automated option.

Why? Because when you model a process with task types, you're usually documenting
the as-is process - how things work today. The whole point
is to highlight where automation potential exists. If you label a partially manual task
as a service task, you hide the very inefficiency you're trying to find.

At Space Z, adjusting the machines is a hybrid job - some settings are digital, some
are physical. By marking it as a manual task, you signal to the
engineering team: "This is a candidate for automation." That's far more valuable
than pretending it's already automated.

  > **The golden rule:** When in doubt, pick the less automated task type.

You're documenting the as-is process to highlight automation potential. Don't hide
inefficiencies by labeling manual work as automated.

  ## Why Task Types Matter

Jessica's hiring process, enriched with task types, tells the engineering team
everything they need to build the automation:

  - Three **user tasks** = three input forms needed in the workflow system

Four service tasks = four automated emails to configure
Two manual tasks = two steps the system can't automate (yet)

A trained engineer can look at the diagram and immediately derive system requirements.
The user tasks tell them exactly how many forms to build and what fields they need.
The service tasks tell them which integrations to set up. The manual tasks highlight
where human intervention is unavoidable - or where future automation could save time.

That's the real power of task types: they bridge the gap between business
people and engineers. Jessica describes the process she needs. The engineering
team reads it and knows exactly what to build. No lost-in-translation meetings, no
ambiguous requirements documents. One diagram, shared understanding.

  ## The Seven Types at a Glance
  - **User task** - A person works in software (filling a form, reviewing a record)

Service task - A machine does the work (API call, automated operation)
Send task - A message or package is dispatched to a recipient
Receive task - A message or package is actively received by a performer
Manual task - Work done without any IT system (hands-on, physical)
Script task - A custom script is executed in a runtime environment
Business rule task - Pre-defined rules are applied to make a decision

For non-technical processes, generic tasks are perfectly fine. But the moment automation
enters the picture, task types become indispensable. They don't just document what
happens - they document how it happens, and that's what makes a process
diagram actionable.

  > **Seven task types:** User (person in software), Service (machine/API),

Send (dispatch), Receive (accept delivery), Manual (hands-on), Script (custom code),
Business Rule (apply pre-defined rules). Each has a unique icon in the upper-left corner.

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.

The Travel Agency: Sub-Processes, Call Activities & Data in BPMN

Crismo Team — Wed, 08 Apr 2026 13:17:00 +0000

You Deserve a Holiday

After mastering events, gateways, and parallel work, you've earned a break. So let's
take a trip to Paradise Island - white sand, turquoise water, zero
exclusive gateways.

There's just one problem. You applied for your visa four weeks ago, and it still
hasn't arrived. Your luggage is packed. Your flight is booked. But the embassy?
Radio silence.

You pick up the phone and call. Turns out the Embassy of Paradise Island is
famously old-fashioned - every process is paper-based, nothing is digitalized. The officer
apologizes and walks you through what's been happening behind the scenes. As you
listen, you sketch the process in BPMN. Suddenly you can see exactly where your
application is stuck - and why it takes so long.

  ## The Documents

The visa process starts the moment you send your documents to the embassy. From a BPMN
perspective, that's a message start event - something arrives from
outside. But this time, we want to make the documents themselves visible in the diagram.

A data object represents any piece of data flowing through a process -
a business document, an email, a form, a letter. It's drawn as a page with a folded
corner, and it connects to tasks with a dashed arrow. The arrow direction tells you
whether the task reads the data (arrow pointing to the task) or writes it
(arrow pointing away from the task).

In the visa process, the first data object is the visa application form you
filled out. The back office reads it to check whether your documents are complete. A second
data object - your supporting documents (passport copies, photos, proof of
accommodation) - flows alongside it.

Data objects are always optional. You don't need to attach one to every
task that touches data. But when you want to highlight which documents matter - for
instance, when designing a document management system - they make the process far
more expressive.

  > **Data objects** (page icon with folded corner) represent documents flowing through

the process. Data stores (cylinder) represent persistent storage. Both are
optional - use them when you want to highlight which data matters.

  ## The Applicant Database

After the back office checks your documents, they create an entry in the embassy's
applicant tracking system. This isn't a document that flows with the process and
disappears - it's a persistent record that outlives your individual application.

That's a data store. Unlike a data object, which exists only during
the process, a data store persists beyond the lifetime of any single process instance.
Think of it as a database, a CRM, a filing cabinet - something that was there before your
application arrived and will be there after it's processed.

The data store is drawn as an open cylinder. When a task writes to it, the arrow points
from the task to the store. When a task reads from it, the arrow goes the other direction.
In the visa process, the back office writes your record to the applicant
database, and later the visa officer reads it when making the final decision.

  ## Three Departments, One Process

Your application doesn't stay in one department. The back office checks
whether documents are complete. The compliance department runs background
checks and verifies document authenticity. The visa officer makes the
final decision.

That's three lanes inside the embassy pool. Each department handles its part, and
the sequence flow crosses lane boundaries to move responsibility from one team to the
next - no extra handover tasks needed.

But here's where it gets interesting. The compliance department's document
verification involves several steps: checking watermarks, validating stamps, cross-referencing
with issuing authorities. It's a process within the process.

  ## Nesting Processes: The Sub-Process

A sub-process lets you take a group of related tasks and collapse them
into a single activity with a small plus sign. Click the plus, and the detail expands.
Close it, and you're back to the high-level view.

When the token reaches a sub-process, it enters the underlying detail and works through
it like any other process - start event, tasks, gateways, end event. Meanwhile, the
token in the parent process waits. Only when the sub-process token reaches
its end event does the parent token get released to continue.

This introduces hierarchy levels in BPMN. The parent process is Level 1 -
a high-level overview. The sub-process is Level 2 - the detailed breakdown. You can
abstract information at Level 1 and provide all the granularity at Level 2.

In the visa process, "Verify documents" is a sub-process. At Level 1, it looks
like a single task. At Level 2, it expands into checking watermarks, validating stamps,
cross-referencing authorities, and recording results. The visa officer doesn't need
to see those details - they just need to know: documents verified, yes or no.

  > **Sub-processes** group related tasks into a collapsible container (marked with a +).

The parent process waits while the sub-process runs. This creates hierarchy: Level 1 is the
overview, Level 2 is the detail.

  ## Reuse: The Call Activity

Now here's the thing. The embassy doesn't just process tourist visas. They
handle business visas, work visas, student
visas, and transit visas. Each visa type has its own process.
But every single one of them needs document verification.

If document verification were a regular sub-process, you'd have five copies of the
same verification steps - one embedded in each visa process. Change one step (say,
add a new security check), and you'd have to update it five times. That's
a maintenance nightmare.

A call activity solves this. It looks like a sub-process - a task with
a plus sign - but with a bold border. That bold border signals: the
underlying process is globally defined. It exists independently and can be
invoked by any process that needs it.

All five visa processes call the same globally defined document verification process.
Update it once, and every visa type benefits. The call activity is BPMN's answer
to reusable components - define once, use everywhere.

The difference is subtle but important:

  - **Sub-process:** The detail belongs to *this* process. It&apos;s embedded.
      One parent, one child.

Call activity: The detail is globally defined. Many parents can call the
same child. Bold border = shared.

## When the Diagram Gets Too Big

The embassy's full visa process - all three departments, all the checks, the
decision tree - is massive. Printed out, it covers an entire wall. Business users
lose track halfway through. That's not useful.

You already know how to use sub-processes to create hierarchy. But sometimes the
process is huge even at one level - too many paths crossing each other, arrows
weaving left and right and looping back.

Link events solve this. They always come in pairs: a throwing
link event and a catching link event. Together, they replace
a sequence flow. The throwing event sends the token, and the catching event receives
it - both carry the same name so you know they belong together.

Link events are useful in two situations:

  - **Avoiding crossing flows:** When a sequence flow would have to cross over
      other flows (reducing readability), replace it with a pair of link events. The throwing
      event sends the token; the catching event receives it on the other side - no crossing
      needed.

Slicing large processes: Cut an oversized process into two or three
manageable sections. For every sequence flow you cut, add one pair of link events to
reconnect. Three cuts = three pairs = six link events. Each section can be read independently.

## Rules for Link Events

Two rules to remember:

  - Only **intermediate** link events exist. There are no link start events
      or link end events.

Link events are for slicing a single process into parts - not for connecting separate follow-up processes. For that, use normal start and end events.

How do you know whether something is a "second part of the same process" or a
"follow-up process"? Ask yourself: What is the goal of this process? In the
shoe shop, the goal was selling shoes. Cleaning them afterward is a different goal - a
follow-up process. But the back office check and the visa officer's decision share
the same goal: processing the visa application. That's one process, potentially
sliced with link events.

  ## The Full Picture

Here's how all these elements come together in the visa process:

  - **Data objects** make the visa application form and supporting documents
      visible as they flow between departments.

A data store represents the applicant database - persistent, shared, outliving any single application.
A sub-process hides the detailed verification steps behind a clean "Verify documents" label at Level 1.
A call activity makes that verification reusable across tourist, business, work, student, and transit visa processes.
Link events slice the overall process into readable sections so no one has to follow arrows across a wall-sized diagram.

Your visa application? It was stuck in the compliance department - the document verification
sub-process was waiting on a response from the issuing authority. Now that you can read
the process, you know exactly where to follow up. And when you finally land on Paradise
Island, you'll appreciate the process that got you there - even if it took a few
extra weeks.

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.

BPMN Best Practices: Modeling Rules That Actually Matter

Crismo Team — Wed, 08 Apr 2026 13:16:24 +0000

No New Elements This Time

This chapter is different. There are no new shapes to learn. Instead, you're getting
a set of modeling rules - the kind of rules that separate clean,
professional process diagrams from expensive wallpaper that nobody reads.

These aren't obscure academic guidelines. They're practical conventions that
immediately improve the correctness, readability,
and expressiveness of every diagram you build.

  ## The 15-Task Rule

For your process to be valuable, other people need to understand it. A process that
only you can read doesn't matter to your organization. Your diagrams need to be
** accessible** - clear enough that a reader can grasp them without
feeling overwhelmed - and expressive - meaningful enough to help
users tackle real business challenges.

The simplest way to achieve both? Ask yourself one question before you start
modeling: how complex does this process actually need to be?

The rule of thumb: don't use more than 15 tasks in one process.
The SpaceZ heat panel process from the previous chapter had 10 tasks - a considerable
size, but still manageable. Once you push past 15 tasks, users start to struggle.
The diagram stops being a tool and starts being a wall of shapes.

Remember Max, the shop assistant from the very first chapter? Max needs instant
information. He doesn't have the time or patience to trace 47 tasks and 12
gateways across a screen-wide diagram. If your process can't be read in a minute
or two, Max will ignore it - and so will everyone else in your organization.

  > **The 15-task rule:** Keep processes under 15 tasks. If it's bigger, split it

into sub-processes. A diagram that can't be read in two minutes won't be read at all.

  ## When to Break the Rule

There is one exception. If your process is designed for technical
users - for example, defining the requirements of an SAP system - it's
fine to exceed 15 tasks. But only if every stakeholder who reads the diagram is
skilled and confident in BPMN.

The key question is always: what is the purpose of my process model?

  - Are you expressing valuable business information for end users?

Are you defining the behavior of a complex IT system?
Are you creating a process for regulatory audits?

Each purpose demands a different scope. A process for Max and a process for a
systems architect are fundamentally different documents, even if they describe the
same workflow.

And if your business process genuinely needs more than 15 tasks? Don't just delete
random tasks to fit the number. In later chapters, you'll learn how to break
complex processes into sub-processes - structured containers that
keep the top-level diagram clean while preserving all the detail underneath.

  ## Naming: Pools and Lanes

Pools and lanes represent responsibilities. It's tempting to label a lane with a
person's name - "Max" - but this is a mistake.

Max may not be the only shop assistant. You don't want a separate process for every
employee. And when Max leaves or a new assistant is hired, the model breaks. Instead,
always label lanes with general roles: a department, a job function,
a team. "Shop Assistant", not "Max." The role should describe who
is responsible for the tasks in that lane, regardless of which specific person fills
the role today.

  ## Naming: Tasks

Tasks represent actions - someone has to do something. Your labels should
reflect that. Compare these two names for the same task:

  - *"Shoe size check"*

"Check if the shoe size is available"

The second one is better. It uses an active verb - "check" - which
makes it immediately clear that action is required. The first version is vague. Is
it a check that was done? A check that needs doing? A check that's being considered?

The convention: verb + noun. "Prepare production plan."
"Adjust machines." "Assess panel quality." Every task label
should read like an instruction - clear enough that the reader knows exactly what
to do.

  > **Naming convention:** Tasks use verb + noun ("Check inventory", not "Inventory").

Events describe states ("Order received", not "Receive order"). Lanes name roles, not people.

  ## Naming: Events

Events are the opposite of tasks. They don't represent actions - they represent
** states or stages**. Something has happened, or something is being
waited for. Your labels should reflect that distinction.

Use passive descriptions: "Payment reminder has been sent."
"Raw material delivered." "Quarter has started." These make it
clear that the event describes a situation, not an instruction.

If your event label sounds like a task - "Send payment reminder" - readers
will get confused. Is it a task or an event? Keep the boundary sharp: tasks are
active, events are passive.

  ## Collaboration: Sequence Flows vs. Message Flows

Here's a mistake so common it deserves its own section. When two lanes inside
the same pool need to communicate - say, the Planning Department hands a production
plan to Quality Assurance - many modelers reach for the message
event. After all, they might send the plan via email.

But this is incorrect. Message events are reserved exclusively for
communication with external parties - participants in a different
pool. For handovers within the same organization, a simple sequence
flow crossing the lane boundary is enough. The arrow says: the work moves
to this role now.

Think of the Bookworm store. When the store communicates with a customer - an
external party in a separate pool - message events and message flows are correct.
But when the sales manager hands off to the warehouse manager within the same store,
a sequence flow across lanes is all you need.

The rule:

  - **Within one pool** → use sequence flows

Between pools → use message events

## Consistent Flow Direction

Every pool must contain a complete process - a path from start event
to end event that runs without interruption. The token must be able to roll from
beginning to end within a single pool.

This matters when you model two separate organizations. Imagine expanding the
Bookworm store process by adding a full customer pool alongside the store pool. Both
pools must contain independent, complete processes. If you removed
one pool entirely, the other should still make sense on its own.

Use two full pools only when necessary - when both processes are
highly important and you need to understand both in detail. For example, when
optimizing the customer journey, you need the customer's perspective modeled just
as thoroughly as the store's internal process.

In most cases, though, a collapsed pool - a simple black bar
representing the external party without showing their internal flow - is enough.
It keeps your diagram focused and reduces complexity.

  ## Straight to Success

This final rule is the one that elevates a correct process diagram into a
professional one.

Look at the shoe store process from Chapter 1. The success path - the ideal
scenario where everything goes right - follows a straight horizontal
line. When a gateway makes a decision and the answer is positive, the
token continues straight ahead. When the answer is negative, the token branches
** downward**.

You could swap the paths and the process would be semantically identical - it
would still be correct. But it would be harder to read. The reader would have to
trace branching paths to find the happy ending, instead of simply following the
straight line.

The convention:

  - **Successful outcome** → go straight

Negative outcome → branch downward

Model the happy path first, as a clear horizontal flow from left to right. Then
add exceptions and error handling as downward branches. This gives every reader -
from Max the shop assistant to a senior process consultant - a consistent,
predictable way to read any BPMN diagram you build.

  ## The Complete Checklist

Five rules. No new symbols. But if you apply these consistently, your process
diagrams will be clearer than those built by people with years more experience.

  - **Scope** - keep processes under 15 tasks for business users. Use
      sub-processes to break up larger flows.

Naming (lanes) - use roles, not people's names.
Naming (tasks) - use verb + noun. Make every label an instruction.
Naming (events) - use passive descriptions. Make every label a state.
Collaboration - sequence flows within a pool, message events between pools. Never use message events for internal handovers.
Complete pools - every pool must contain a full, independent process from start to end.
Straight to success - the happy path goes straight, exceptions branch downward.

Apply these rules and your processes stop being diagrams. They become tools -
readable, maintainable, and useful to everyone in the organization.

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.

The Space Ship: Timer, Conditional & Attached Events in BPMN

Crismo Team — Wed, 08 Apr 2026 13:15:48 +0000

Welcome to SpaceZ

SpaceZ is a private spaceship manufacturer. Their spacecraft re-enter
the atmosphere at thousands of degrees - and the only thing standing between the crew
and incineration is a set of heat-resistant panels. The engineering
team has just developed a new generation of these panels. Now it's up to the production
team to manufacture them.

The stakes are high. A faulty panel could endanger lives. The process needs to be fast,
precise, and crystal clear - with built-in safeguards for when things go wrong. Three
teams are involved: the Planning Department, which procures raw
materials and creates the production plan; Quality Assurance, which
checks both the plan and the finished samples; and the Production Team,
which adjusts machinery and manufactures the panels.

To model this process, you need elements you haven't seen before - events that react
to time, events that react to conditions, and events that can
interrupt a task that's already running.

  ## When Time Is the Trigger

SpaceZ's development department hands over new products on a quarterly schedule. The
production process doesn't start when someone presses a button - it starts when
a new quarter begins. That's a timer start event.

In BPMN, timer events are drawn with a small clock symbol inside the circle. They
represent specific dates, deadlines, or durations. Think of an audit triggered at
the start of every quarter, or a warehouse check that takes exactly one week.

Here's a crucial detail: timer events are always catching events.
Why? Because time isn't something you can trigger - it simply happens. You can send
a message (that's a throwing event), but you can't send time. You can only
wait for it. That's why BPMN has no throwing timer events.

  > **Timer events** use a clock symbol. They represent dates, deadlines, or durations.

Timer events are always catching - you can't send time, only wait for it.

  ## Waiting for a Condition

Timer events wait for a point in time. Conditional events wait for
a situation to become true.

Imagine a warehouse where stock is running low. The condition "only one unit left
in stock" is either true or false. A conditional event holds the token in place
until the condition flips to true - then the process continues.

Like timer events, conditional events are always catching. Whether a
condition becomes true or not cannot be directly controlled - it depends on the state
of the world. So in BPMN, conditional events simply happen, just like time does.

  ## A Quick Detour: The Bakery

Before we return to SpaceZ, here's a simple example that shows both event types
working together - a bakery process:

  - The process starts with a **timer start event** - triggered every day.

The staff prepares the dough.
A timer intermediate event pauses the process for 25 minutes while the dough rises.
The dough goes into the oven.
A conditional intermediate event holds the token until the condition "the bread is brown" becomes true.
The staff takes the bread out. Process complete - freshly baked bread.

Simple, but it shows the concept: timers wait for a moment, conditionals
wait for a state. Now let's apply these ideas somewhere the stakes are much higher.

  ## Events Attached to Tasks

So far, you've only seen events between tasks - one task ends, the event
fires, the next task begins. But BPMN has a more powerful trick: events can be
** attached directly to a task**.

An attached event sits on the boundary of a task - literally drawn on its edge. While
the task is being worked on, the event listens. If the event triggers while the task
is still running, it interrupts the task and redirects the token to
an alternative path.

Think of a task with a deadline. If the deadline expires while the work is still in
progress, the attached timer event fires, the task is cancelled, and the process
takes a different route - perhaps delegating the work to someone else.

Only catching events can be attached to tasks. This makes sense -
attached events are waiting for something to happen while the task runs.
You can attach timer events, conditional events, message events, and more.

  > **Attached events** sit on the boundary of a task. If triggered while the task

is running, they interrupt it and redirect the token to an alternative path. Only
catching events can be attached.

  ## An Example: The Bookworm Store

Here's a quick illustration. In the Bookworm store, when a book is
out of stock, the sales manager must procure it. But the store has a policy:
customers can cancel their order at any time during procurement.

While the sales manager is working on procurement, the token stays inside the task.
If the customer cancels, a conditional event attached to the task
fires. The procurement stops immediately, and the token takes the alternative path
to handle the cancellation.

The key insight: the sales manager stops the current task and continues
with whatever the alternative flow requires. The attached event doesn't wait for the
task to finish - it interrupts it.

  ## The Heat Panel Process: Success Path

Back to SpaceZ. Here's how the serial production of new heat panels unfolds when
everything goes right - the success path:

  - A **timer start event** triggers the process at the beginning of each
      quarter, aligning with the development department's handover schedule.

The Planning Department checks if enough raw material is available. If yes, the token passes through an exclusive gateway and moves forward.
The Planning Department creates the production plan. The token then passes a ** plain intermediate event** - a milestone marker that doesn't influence the flow. It simply says: "we've reached an important point."
A parallel gateway splits the token: Quality Assurance assesses the plan while the Production Team informs staff about the upcoming work.
Both tokens merge at a closing parallel gateway. An exclusive gateway checks whether Quality Assurance approved the plan.
If approved, the Production Team adjusts the machines and produces the first samples. Note the attached conditional event on this task - if visual defects appear during production, the event fires and stops the task immediately.
Assuming no defects, Quality Assurance inspects the samples. If they pass all material tests, the panels are approved and the process ends successfully.

Ten tasks, three teams, one clean path from start to finish. That's the ideal
scenario. But SpaceZ doesn't live in an ideal world.

  ## When the Material Isn't There

What happens when the raw material check fails? The token takes the downward path.
The Planning Department records the missing components, and the token reaches an
event-based gateway.

The event-based gateway is the fourth and final gateway in BPMN. Unlike the others,
it doesn't make a decision - it waits for external events. The process
pauses until one of several possible events occurs. Like the exclusive gateway, only
one path activates - but the choice is made by which event happens first,
not by a condition.

At SpaceZ, two events are possible:

  - The components arrive - a **catching message event** fires, and the
      process continues with production planning.

Three days pass with no delivery - a timer event fires, and the Production Team sources the components directly from the supplier.

Only one of these events can occur. Even if the components arrive at the exact same
millisecond the timer expires, BPMN assumes one happens slightly before the other.
No ambiguity.

  ## When the Plan Gets Rejected

Quality Assurance reviews the production plan and finds issues. The token is sent
back to the Planning Department for adjustments. Once updated, the revised plan
returns to Quality Assurance for re-assessment while the Production Team informs
staff about the changes.

This time Quality Assurance is satisfied. The plan is approved, and the Production
Team can begin adjusting the machines.

  ## When the Samples Fail

During production, the attached conditional event detects visual defects in the
samples - a cut in the panel surface. The event fires immediately. Production stops.
The token takes the alternative path back to the machine adjustment step.

The Production Team readjusts the machines and produces a second batch. This time
no visual defects appear, but Quality Assurance still isn't satisfied with the
material test results. The samples are rejected, and the cycle repeats - a third
round of machine adjustment and sampling.

Finally, the third batch passes all inspections. Quality Assurance approves the
samples, and the process terminates successfully.

  ## What You've Learned

With the elements from this chapter, you can now model about 90% of the
processes you'll encounter in the real world. Here's what you've added to
your toolkit:

  - **Timer events** - represent specific dates, deadlines, and durations.
      Always catching, because time simply happens.

Conditional events - represent conditions that are either true or false. Always catching, because conditions can't be directly controlled.
Attached (boundary) events - sit on a task's edge and interrupt it when they fire. Only catching events can be attached.
Event-based gateway - waits for one of several events to occur, then takes that path. Closed with an exclusive gateway, since only one path activates.

The SpaceZ process combined all of these: a timer that starts the quarterly cycle,
conditions that halt production when defects appear, attached events that interrupt
tasks mid-execution, and an event-based gateway that waits for materials or a
deadline. These are the tools for processes where timing, exceptions, and external
triggers matter.

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.

BPM Traps: Deadlock & Multimerge in BPMN

Crismo Team — Wed, 08 Apr 2026 13:15:12 +0000

No New Elements This Time

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.

  ## Trap 1: The Deadlock

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.

  ## Gonzalez Is Still Waiting

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.

  ## Trap 2: The Multimerge

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.

  ## Ghost Tasks at the Bookworm Store

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.

  ## Deadlock vs. Multimerge

Both traps come from the same root cause - mismatched gateways. But their consequences
are very different:

  - **Deadlock** is a *technical error*. The process gets stuck and
      cannot complete. It must be fixed - there's no working around it. The token is trapped
      forever.

Multimerge is technically correct but practically dangerous. The process runs, but tasks execute more times than intended. It compromises the clarity and expressiveness of your model.

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 Rule

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.

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.

Beauty Paradise: Inclusive Gateways & Message Events in BPMN

Crismo Team — Wed, 08 Apr 2026 13:14:36 +0000

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.

Bankovia: Event-Based Gateways, Compensation & Cancel Events in BPMN

Crismo Team — Wed, 08 Apr 2026 13:14:06 +0000

A Bank Joins the 21st Century

Bankovia is the kind of bank where the loudest sound is a rubber stamp
hitting paper. Old-fashioned, reliable, and deeply allergic to change. But even their
most loyal customers have started demanding digital services. So Bankovia's management
makes a bold decision: build an app that lets customers transfer money.

Simple, right? Except that a money transfer touches multiple systems, waits for external
confirmations, and needs to handle fraud, timeouts, and cancellations - all gracefully.
The process behind that "Send Money" button will teach us the remaining BPMN events:
** event-based gateways*, **compensation events, and
* cancel events**.

  ## The Event-Based Gateway: A Race Between Events

You already know the exclusive gateway - a diamond with an X that makes a decision based
on data. "Is the shoe in stock? Yes or No." The answer is known at the moment
the token arrives.

The event-based gateway is different. It doesn't evaluate data - it
waits. The token arrives at the gateway and pauses. Multiple events are defined
as possible next steps - a message, a timer, a signal - and whichever event occurs
first wins. The other paths are discarded.

Think of it as a race. The gateway fires a starting pistol, and three runners take off:
"confirmation received," "24 hours elapsed," "user cancelled." The first one across the
finish line determines what happens. The other two stop running.

In Bankovia's transfer process, after the money is sent to the recipient bank, the
event-based gateway waits. Will the other bank confirm the transfer? Will 24 hours pass
without a response? The outcome determines whether the transfer succeeds or gets rolled back.

  > **Event-based gateway:** The token waits. Multiple events race. Whichever

happens first wins - the other paths are discarded. It evaluates events, not data.

  ## The Compensation Event: Rewinding the Tape

Sometimes work gets completed - fully, successfully completed - and then something
happens that means it needs to be undone. The money was deducted from the
sender's account. The transfer failed. Now you need to put that money back.

The compensation event handles this. Its symbol is a rewind icon - two
triangles pointing backward - because that's exactly what it does: reverses completed work.

The notation has a specific pattern:

  - A **compensation boundary event** is attached to the task that might need
      undoing. It&apos;s connected by a dashed association line to a compensation
      task that describes *how* to undo the work.

A throwing compensation event (intermediate or end) triggers the compensation. When the token reaches it, the attached compensation boundary event fires, and the compensation task executes.

The key rule: the original task must already be completed before it can be
compensated. You can't undo work that hasn't been done. The boundary event doesn't
interrupt the task - it waits until after completion, then activates if triggered.

  > **Compensation** undoes completed work. Three parts: a boundary event on the

original task, a compensation task describing the undo, and a throwing event that triggers it.
You can only compensate work that's already done.

  ## The Cancel Event: Ending a Transaction

The cancel event has one purpose: cancelling a
** transaction sub-process**. Remember that a transaction represents a logical
unit of work that either succeeds, gets cancelled, or ends in a hazard (critical failure).

Cancel events come in two forms:

  - **Cancel end event** - placed *inside* the transaction sub-process.
      When the token reaches it, the transaction is cancelled.

Cancel boundary event - attached to the outside of the transaction sub-process. It catches the cancellation and routes the token to an alternative path.

You can only use cancel events with transaction sub-processes - never with regular
sub-processes or tasks. They exist solely for this purpose.

  ## Bankovia&apos;s Money Transfer: The Setup

The transfer process starts when a customer opens the app and provides the transaction
details: recipient name, IBAN, amount. The app validates that all mandatory fields are
filled, then the Transaction Management System takes over.

First, it verifies the IBAN. Then two things happen in parallel (a parallel gateway):

  - **SMS TAN authentication** - a one-time code is sent to the customer&apos;s
      phone. They enter it, the system verifies it.

Fraud check sub-process - three automated checks run in sequence: checking user metadata for irregularities (script task, internal data), verifying recipient account credibility (service task, external APIs), and comparing the transaction against known fraudulent patterns.

If the fraud check passes, both tokens meet at the closing parallel gateway, and the
process moves on to the actual transfer. If it doesn't - things get serious.

  ## Scenario 1: Fraud Detected

The fraud check fails. One or more of the three tests flags the transaction. The
sub-process ends with an escalation end event, which triggers an
attached escalation event on the sub-process boundary.

The alternative path kicks in: the compliance and IT security team is notified, the
customer's account is temporarily blocked, and the customer is informed.

But there's a problem. The SMS TAN path already completed - that token is sitting at
the parallel gateway, waiting for the fraud check token that will never arrive through
the normal path. If we end with a regular end event, that waiting token stays forever.
The process never finishes.

This is exactly where the terminate event earns its keep. At the end of
the fraud-handling path, a terminate end event kills every remaining token in the process
instance - including the one stranded at the parallel gateway. Clean shutdown.

  ## Scenario 2: Bank Not Reachable

The fraud check passes. Both tokens synchronize. The
** transaction sub-process** begins.

First, the transfer amount is deducted from the sender's account (a script task -
purely internal). Then the money is sent to the recipient bank (a service task -
external API calls to the other bank's systems).

Now the process reaches the event-based gateway. It waits for one of
two events:

  - A **confirmation message** from the recipient bank.

A 24-hour timer - if no confirmation arrives in time.

In this scenario, the timer wins the race. No confirmation after 24 hours. The transfer
failed.

The token moves through the timer event to a throwing compensation event.
This triggers the compensation boundary event attached to the "deduct
amount" task. The compensation task executes: the deducted amount is refunded to the
sender's account.

Simultaneously, the token reaches a cancel end event inside the
transaction. This triggers the cancel boundary event on the transaction
sub-process, routing to the cancellation path: an email is sent to the customer asking
them to retry the transfer later.

Two mechanisms working together: compensation undoes the completed work (the deduction),
and the cancel event handles the transaction-level outcome (the cancellation flow).

  ## Scenario 3: System Failure

The transaction starts normally. The amount is deducted, the money is sent. But during
the transfer, the entire Transaction Management System crashes. This triggers an
** attached error event** on the transaction sub-process.

The error event is always interrupting - the transaction stops immediately. The
alternative path investigates the error and performs mitigation actions. This is the
hazard state of the transaction: neither a clean success nor a
controlled cancellation, but an unexpected failure.

Remember the three outcomes of a transaction sub-process: success, cancellation, or
hazard. The error event handles the hazard case.

  ## Scenario 4: The Happy Path

Finally, the scenario Bankovia hopes for. The amount is deducted, the money is sent,
and the event-based gateway waits. This time, the confirmation message
arrives before the 24-hour timer fires.

The token follows the confirmation path, the transaction completes successfully, and
the parent process ends. The customer sees a green checkmark in the app. Done.

This is the success state of the transaction - the logical unit of work
completed without cancellation or failure.

  ## How the Pieces Fit Together

Bankovia's process is a masterclass in combining BPMN events:

  - **Event-based gateway** - waits for whichever event arrives first
      (confirmation vs. timeout). Use when the next step depends on external events
      outside your control.

Compensation - undoes completed work (refunds the deducted amount). Use when a later failure means earlier successful work needs to be reversed.
Cancel event - ends a transaction sub-process and triggers a cancellation flow. Use with transaction sub-processes to handle controlled cancellations.
Error event - handles system failures (the hazard state). Use for unrecoverable technical failures.
Escalation event - routes fraud detection to the compliance team without crashing the process. Use when a problem needs attention but the response is a defined alternative path.
Terminate event - kills orphaned tokens (the one stuck at the parallel gateway after fraud detection). Use when other tokens would be stranded without it.

Each event has a specific job. Compensation rewinds. Cancel ends transactions. Error
handles crashes. Escalation bumps up. Terminate wipes the board. Knowing which one to
reach for - that's what separates someone who knows BPMN notation from someone who
can actually model a real process.

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.

Nilla Care: Signals, Errors, Escalation & Termination in BPMN

Crismo Team — Wed, 08 Apr 2026 13:14:02 +0000

Where Safety Is the Product

Nilla Care is a small hospital where risk management isn't a department -
it's a culture. Energy blackouts, equipment failures, medication errors - any of these
could endanger patients and staff. To keep risks in check, Nilla Care maintains a set of
controls: fire extinguishers in the right locations, backup generators that actually start,
medication protocols that nurses actually follow.

But having controls isn't enough. You have to test them. Regularly. Rigorously.
This quarter, Nilla Care needs to test 10 controls. The process for doing so will teach
us four advanced BPMN events: signals, errors,
** escalations*, and **termination*.

  ## The Signal Event: Broadcasting to Anyone Listening

Before we step inside the hospital, let's understand signals with a simpler example.
Imagine a tofu company wins a major reference customer. They want to announce it - not to
a specific person, but to the world. A blog post, a logo on the website, maybe a webinar.

In BPMN, this undirected broadcast is a signal event. Unlike a message event
(which is sent to a specific recipient), a signal event broadcasts information
that isn't addressed to anyone in particular. Think of it like a radio station - it
transmits, and anyone tuned to the right frequency picks it up.

On the sending side, a signal end event (or throwing intermediate signal)
broadcasts the information. On the receiving side, a signal start event (or
catching intermediate signal) listens and triggers a process when the signal arrives.
The sender doesn't know - or care - who's listening. That's what makes it different
from a message.

Signals are versatile. They can be used as start events, intermediate events (both catching
and throwing), boundary events (interrupting and non-interrupting), and end events. They
can even trigger event sub-processes. Of all the advanced events, signals have the widest
range of uses.

  ## The Error Event: When Something Breaks

An error event represents a technical failure - something went wrong that
shouldn't have. In BPMN, errors are always exceptional and always interrupting. There's
no "non-interrupting error" because when a system fails, you can't just keep going as if
nothing happened.

Error events have three forms:

  - **Error end event** - placed inside a sub-process to signal that something
      failed. It terminates the sub-process immediately.

Attached error event - a catching boundary event on a sub-process. When the error end event fires inside, this boundary event catches it and routes the token to an alternative "error handling" path.
Error start event - used only to trigger an interrupting event sub-process.
BPMN assumes errors are exceptions, so they only start event sub-processes, never
normal processes.

## The Escalation Event: Bumping It Up

Not every problem is a catastrophic failure. Sometimes things just need to be
bumped up to a higher authority. A delivery is five days late - that's not
an error (the system didn't crash), but it's a problem that someone more senior should
know about.

The escalation event handles this. Unlike errors, escalations can be
non-interrupting. The original work can continue while the escalation triggers
a parallel path. The late delivery keeps being tracked, and the customer gets
notified about the delay.

Escalation events are especially useful for communication between parent processes and
sub-processes. A throwing escalation event inside a sub-process can trigger a catching
escalation event in the parent scope - connecting the two levels without stopping either.

  ## The Terminate Event: The Nuclear Option

The terminate event is the most drastic end event in BPMN. When a token
reaches a terminate end event, it doesn't just end its own path - it kills every token
in the current process instance, including tokens in sub-processes. Everything stops.
Immediately.

This only exists as an end event - which makes sense. Its entire purpose is to end
everything, right now. You use it when a situation is so severe that no other work in
the process should continue. A fraudulent transaction detected? Terminate. Kill the
token that's still waiting at the parallel gateway, kill the token in the verification
sub-process, kill everything.

Use it sparingly. In most cases, you can achieve the same result with cancelling event
sub-processes or attached interrupting events. But when you need a clean, unmistakable
"stop everything" - the terminate event is your tool.

  ## Nilla Care&apos;s Control Testing Process

Now let's see all four events in action. The process begins with defining the scope and
parameters for the quarterly control assessment. Last year's control report is pulled
in as a reference - controls that failed before get extra scrutiny this time.

The actual testing lives inside a sequential multi-instance sub-process.
Each of the 10 controls goes through the same flow, one by one. For each control, two
tests run in sequence:

  - **Assess control design** - is the control designed correctly for the risk
      it&apos;s supposed to mitigate? A fire extinguisher rated for electrical fires in a kitchen
      with grease fires would fail this test.

Check operational performance - does the control actually work? Is the fire extinguisher charged, accessible, and in the right location?

If both tests pass, the control is marked as passed, and the sub-process moves to the
next instance. Controls 1 through 6 sail through without issues.

  ## Control 7: The Escalation

Control number 7 doesn't pass. One or both tests reveal a problem. Now the team
needs to define remediation measures - specific actions to fix the
control so it actually works.

After documenting the remediation plan, a throwing escalation event fires.
This triggers an event sub-process that implements the remediation in
parallel: the fix is applied, then documented.

Meanwhile, the main sub-process flow continues - compiling a dedicated control testing
report for this specific control. Two paths running simultaneously: one fixing the
problem, one documenting the test results. Neither blocks the other.

When both paths complete - no more active tokens - the sub-process instance for
control 7 finishes, and the sequential multi-instance moves to control 8.

  ## Control 8: The Deadline

Control 8 has a different problem. During the design assessment, it turns out that everyone
qualified to perform the test is on sick leave or vacation. The task stalls.

Each control test has a deadline. When that deadline passes, a cancelling timer
event sub-process fires - note the solid (not dashed) border on the start event.
This is interrupting: the token in the design assessment task gets killed.

The team provides a justification for the missed deadline and flags the control for the
next testing round. The current instance of the sub-process completes - but only this
instance. The sequential multi-instance continues with control 9.

This is a crucial distinction: an interrupting event sub-process cancels
the current instance of the multi-instance sub-process, not the entire
multi-instance. The loop continues.

  ## Controls 9 and 10: The System Failure

Control 9's design assessment passes. But during the operational performance check, the
IT system used to document testing results crashes completely. This triggers an
** attached error event** on the sub-process boundary.

Here's where it gets critical. Unlike the event sub-process from control 8 (which only
cancelled the current instance), an attached boundary event cancels the entire
multi-instance sub-process - all remaining instances, not just the current one.
Control 10 never gets tested through this path.

This makes perfect sense: the IT system is down. It's not a problem with one control -
it's a systemic failure. Every remaining control would face the same issue.

The token exits the sub-process and takes the alternative path: manual control
testing for the remaining controls (9 and 10). When that's done, the central
compliance team compiles the global control report, aggregating results
from all 10 controls - the six that passed, the one that needed remediation, the one
that missed its deadline, and the two that required manual testing.

  ## Choosing the Right Event

Nilla Care's process demonstrates when to use each event type:

  - **Signal** - broadcast information without a specific recipient. Use when
      the sender doesn&apos;t know (or care) who&apos;s listening.

Error - a critical failure that must stop the current scope. Always interrupting. Use for system crashes, data corruption, or anything that makes continuing impossible.
Escalation - a problem that needs attention from a higher level, but doesn't necessarily stop the current work. Can be interrupting or non-interrupting. Use for delays, quality issues, or anything that requires management awareness.
Terminate - kill every token in the process. Use as a last resort when the entire process instance must stop immediately.

The key insight: BPMN gives you a spectrum of severity. Escalation is a yellow flag.
Error is a red flag that stops the sub-process. Terminate is pulling the emergency brake
on the entire train.

  > **Spectrum of severity:** Signal = broadcast (anyone listening).

Escalation = yellow flag (bump it up). Error = red flag (stop this scope).
Terminate = emergency brake (kill everything).

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.

The Race Track: Parallel Work in BPMN

Crismo Team — Wed, 08 Apr 2026 13:13:34 +0000

The Token

Before we hit the racetrack, you need to understand one concept that makes BPMN click:
the token.

Imagine a marble rolling through your process diagram. It starts at the start event,
passes through tasks one by one, and eventually reaches the end event. When a task is being
worked on, the marble sits there and waits. When the task is done, the marble rolls
forward to the next element.

At an exclusive gateway (which you learned in the Shoe Shop), the marble takes one path.
Simple. But what happens when work needs to happen at the same time?

  > **Token concept:** Imagine a marble rolling through your diagram. At a parallel

gateway, the marble is cloned. At an exclusive gateway, the marble picks one path.
At a closing gateway, the marbles merge back into one.

  ## Meet Gonzalez

Gonzalez is a Formula One driver. Successful, famously impatient, and leading the field
in the final race of the season. Ten laps in, he needs a pit stop. His team has to
** change the tires** and refuel the car - and they need to do
it simultaneously. Every second in the pit costs positions on the track.

If the fuel team had to wait for the wheel team to finish, or vice versa, the pit stop
would take twice as long. Gonzalez would lose the championship. The process needs to
express: "these things happen at the same time."

  ## The Parallel Gateway

That's what the parallel gateway does. It looks like a diamond with a
** plus sign** inside - and unlike the exclusive gateway, it has no question
on top. No decision is being made. It simply says: "all paths activate simultaneously."

Back to the token concept: when the marble hits a parallel gateway, it gets cloned.
If there are two outgoing paths, you now have two marbles. Three paths, three marbles.
Each one rolls independently through its branch.

At the other end, a closing parallel gateway waits. It knows how many
marbles to expect. It won't release a single marble until all of them have arrived.
That's the synchronization point - the moment where parallel work comes back together.

  > **Parallel gateways** are diamonds with a plus sign. They activate all outgoing

paths at once - the token is cloned. The closing gateway waits for every clone to arrive
before releasing a single token forward.

  ## The Pit Stop

Here's how Gonzalez's pit stop works in BPMN:

The process starts when Gonzalez pulls into the pit lane. The token hits the parallel
gateway and splits into two:

  - **Wheel team path:** Loosen screws → Remove tires → Mount new tires → Fasten screws

Fuel team path: Open gas cap → Refuel tank → Close gas cap

Both teams work at the same time. The wheel team is fast - four tasks done in seconds.
The fuel team is slightly slower - refueling takes longer. Gonzalez is getting nervous.

But the closing gateway waits patiently. It doesn't release Gonzalez until both tokens
arrive. The fuel team closes the gas cap, the second token reaches the gateway, and
Gonzalez rockets back onto the track.

  ## Why This Matters

The parallel gateway isn't just for racing. It shows up everywhere:

  - A hiring process where reference checks and background verification happen simultaneously

An order process where payment processing and warehouse picking happen in parallel
A patient admission where insurance verification and room assignment happen at the same time

Whenever you hear "at the same time," "simultaneously," or "in parallel" - that's a
parallel gateway.

  ## Don't Confuse the Gateways

The exclusive gateway (X) and parallel gateway (+) look similar. Even experienced modelers
mix them up. Build a mental bridge now:

  - **Exclusive (X):** Think "cross out" - you're crossing out all paths except one

Parallel (+): Think "plus" - you're adding all paths together

One makes a choice. The other doesn't choose - it does everything.

  > **Exclusive (X):** Cross out all paths except one.

** Parallel (+):** Add all paths together. Build this mental bridge now -
it will save you from the traps in Chapter 4.

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.

The Shoe Shop: Your First BPMN Diagram

Crismo Team — Wed, 08 Apr 2026 13:13:30 +0000

Meet Max

Max has been working at MegaWorld Shoes for exactly three weeks. He's 23, fresh
out of university, and this is his first real job. So far he's been doing great - friendly with
customers, quick on the register, always on time.

But today is different. A woman walks in, picks up a pair of running shoes, and says:
"Do you have these in a 38?"

Max checks the shelf. No 38. He looks around - his manager Elena is on lunch break.
The other assistant is helping someone else. Max is on his own, and he has no idea whether
he should check the warehouse, call another store, or just apologize.

Then he remembers. During his onboarding, Elena mentioned something about a process handbook.
He pulls it up on the store tablet and finds: "Missing Shoe Size - What To Do."

It's a diagram. A flow chart, but more precise. It tells Max exactly what to do, step by step,
for every possible outcome. This diagram is written in BPMN - and by the end of this
chapter, you'll be able to read it too.

  ## How It Starts, How It Ends

Every process has a trigger - something that sets it in motion. For Max, it's the moment
a customer asks for a shoe size that isn't on the shelf. That's a start event.

In BPMN, start events are drawn as thin circles. They don't ask anyone to do anything -
they describe a situation. Something happened. The process has begun.

At the other end, there's an end event - a thick circle. The process
is done. Max has handled the situation, one way or another.

  > **Events** are circles. They represent states or situations - things that happen.

A thin circle starts the process. A thick circle ends it.

  ## Max's First Job

The process tells Max what to do first: check the local warehouse.
Not "think about it" or "wait for Elena." A clear, concrete action.

In BPMN, actions are called tasks - rounded rectangles. Unlike events
(which just happen), tasks require someone to act. Max has to walk to the back,
look through the shelves, and find out if the size 38 is hiding somewhere.

The arrow connecting the start event to the task is a sequence flow.
It says: "after this situation occurs, do this."

  > **Tasks** are rounded rectangles. They represent work that someone needs to do.

** Sequence flows** (arrows) connect elements and show the order.

  ## The Moment of Truth

Max comes back from the warehouse. Either he found the shoes, or he didn't.
What happens next depends entirely on the answer.

This is a gateway - a diamond shape with a question on top:
"Shoe in stock?" It's called an exclusive gateway because
exactly one path is taken. Yes or no. Never both.

If yes - great. Max grabs the shoes from the rack and sells them to the customer.
Two quick tasks and the process ends happily.

  > **Exclusive gateways** are diamonds. They represent decisions where exactly one path is

chosen. A question sits on top. The answer determines which way the process goes.

  ## The Happy Path

Let's say Max is lucky. He walks into the warehouse, spots the box on the second shelf,
and pulls out a perfect size 38. Back on the shop floor, he hands them to the customer,
rings up the sale, and feels like a professional.

In BPMN, this is called the happy path - the ideal scenario where
everything goes right. Start, check warehouse, shoes found, sell, done.

Notice the diamond at the end. That's a closing gateway. It doesn't make
a decision - it just collects all the paths back together before the end event. Think of it as
a meeting point: no matter which route Max took, the process finishes here.

  ## When Things Don't Go as Planned

But today isn't Max's lucky day. The warehouse has plenty of 37s and 39s, but no 38.
The customer is waiting. What now?

The process has an answer. The "No" branch tells Max to call the second store
across town. MegaWorld has two locations - maybe they have it.

Another gateway: "Available at second store?" If yes, Max refers the customer there.
If no, there's one last option - call express delivery, find out when the shoes can
arrive, and let the customer know.

Three possible outcomes, three different paths, but all leading to the same end. Max always
knows what to do next. No guessing, no awkward "let me ask my manager." The process handles it.

  ## Adding Roles: Who Does What

Fast forward two months. MegaWorld is growing. Elena hires three more shop assistants. None of
them have dealt with missing shoe sizes before. Without the process diagram, Elena would explain
the same procedure four times. With it, she points new hires to the tablet on day one.

Growth also brings a new role: a warehouse manager. Pulling shoes from the rack
is no longer Max's job. But the diagram needs to show who does what.

A pool represents the organization - "MegaWorld Shoes" is a pool. Inside it,
** lanes** divide responsibility. Adding a "Warehouse Manager" lane means the
"take shoes from rack" task moves to the right person.

  > **Pools** represent organizations. **Lanes** divide pools into roles

or departments. A sequence flow crossing a lane boundary means the work moves to another role.
No extra "handover" task needed.

A common mistake: people think you need an extra task for handovers between roles. "Tell the
warehouse manager" or "wait for confirmation." You don't. In BPMN, a sequence flow crossing
a lane boundary is enough. The arrow says: the work moves to this role now.

  ## The Power of Writing It Down

This is Max's complete process. Two decisions, seven tasks, three possible outcomes.
It fits on a single screen, and any new hire at MegaWorld can read it on day one.

That's the real point. Not the shapes and arrows - those are just notation. The power is that
** everyone in the organization agrees on how this works**. When Elena hires
three more assistants next month, she won't explain the missing shoe size procedure
four times. She'll point them to this diagram.

And when MegaWorld eventually hires that warehouse manager, one line in the diagram
changes - the "take shoes from rack" task moves to a different lane. The process evolves
with the business.

  > Every BPMN diagram uses the same building blocks:

** events** (what happens), tasks (what needs doing),
** gateways** (decisions), and sequence flows (the order).

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.

BPMN Tools Compared: 15 Process Modeling Tools for 2026

Crismo Team — Wed, 08 Apr 2026 13:10:27 +0000

BPMN Tools Compared: 15 Process Modeling Tools for 2026

Choosing the right BPMN tool can be overwhelming. There are enterprise suites, open-source editors, general-purpose diagramming apps, and everything in between. Some do real BPMN validation, others just give you shape libraries. Some cost six figures, others are free.

We reviewed 15 process modeling tools and categorized them by what they're actually good at - so you can skip the marketing pages and find what fits your needs.

Not sure which tool is right for you? Take our free 2-minute quiz - answer 5 questions and get a personalized recommendation with a PDF report.

Enterprise BPM Suites

These are the heavy hitters. Full lifecycle process management, governance, compliance, process mining - the works. They come with enterprise pricing to match.

ARIS

The original. Software AG's ARIS practically invented the EPC notation and has been the standard in enterprise process management for decades. If your organization runs SAP and needs formal process governance, ARIS is probably already on the shortlist.

Best for: Large enterprises with formal BPM governance requirements.

SAP Signavio

Now part of the SAP ecosystem, Signavio combines process modeling with process mining. If you're already in SAP's world, the integration story is compelling. The process mining capabilities help you compare how processes are designed vs how they actually run.

Best for: SAP shops that want modeling + mining in one platform.

iGrafx

Enterprise process management with simulation capabilities. iGrafx lets you model processes and then simulate them to find bottlenecks before they happen in production. Strong in regulated industries.

Best for: Organizations that need process simulation and compliance documentation.

ADONIS

BOC Group's process management platform is particularly strong in the DACH region (Germany, Austria, Switzerland). Full BPMN support with a focus on process documentation and governance.

Best for: European enterprises, especially in the DACH region.

IBM Blueworks Live

IBM's cloud-based process modeling tool. Built for enterprise collaboration - think workshops where business stakeholders and analysts map processes together. Less technical than some alternatives, which is the point.

Best for: Enterprise teams doing collaborative process discovery workshops.

Trisotech

The standards purist's choice. Trisotech supports the full OMG suite: BPMN, DMN (decision modeling), and CMMN (case management). If you need all three notations working together, Trisotech is one of the few platforms that does it properly.

Best for: Organizations that need BPMN + DMN + CMMN together.

Process Automation Platforms

These tools go beyond modeling - they execute your processes.

Camunda

The developer's process engine. Camunda lets you model BPMN processes and then actually run them. It's open-source at its core, with a cloud platform for production workloads. If your team writes code and wants to orchestrate microservices with BPMN, Camunda is the go-to.

Best for: Developer teams automating workflows and orchestrating microservices.

Bizagi Modeler

Bizagi offers a free desktop BPMN modeler (Windows only) that's genuinely good for learning BPMN. The modeler feeds into Bizagi's automation platform if you want to go further. It's one of the few tools where the free tier is actually useful.

Best for: Learning BPMN on Windows. Solid free option for documentation.

Process Mining

Not a modeling tool per se, but increasingly part of the BPM conversation.

Celonis

The market leader in process mining. Celonis connects to your ERP/CRM systems and shows you how processes actually run based on event logs. It doesn't replace your modeling tool - it tells you whether your models match reality.

Best for: Enterprises that want data-driven process optimization.

General-Purpose Diagramming

These aren't BPMN tools. They're diagramming tools that happen to include BPMN shapes. Important distinction: they won't validate your BPMN, enforce notation rules, or help you build correct models.

draw.io

Free, browser-based, and incredibly popular. draw.io (now diagrams.net) is many people's first encounter with "BPMN." But here's the thing: draw.io gives you BPMN shapes without BPMN rules. You can create diagrams that look like BPMN but violate the specification in a dozen ways. Great for quick sketches, problematic for real process documentation.

Best for: Quick, informal diagrams. Not recommended for standards-compliant BPMN.

Lucidchart

Polished diagramming with great real-time collaboration. Lucidchart includes BPMN shape libraries and templates. Like draw.io, it won't enforce BPMN rules, but the collaboration features are best-in-class for a diagramming tool.

Best for: Teams that prioritize collaboration and don't need strict BPMN compliance.

Microsoft Visio

The corporate default. If your company runs Microsoft 365, Visio is probably available. It has BPMN stencils and the interface is familiar to anyone who's used Office. But it's a desktop-first tool in a cloud-first world, and BPMN support is surface-level.

Best for: Microsoft shops that need "good enough" process diagrams.

Miro

Miro is a whiteboard, not a diagramming tool - and that's fine. It's excellent for workshops, brainstorming, and collaborative process discovery. Just don't expect it to produce specification-compliant BPMN. Use Miro to explore, then move to a proper BPMN tool for documentation.

Best for: Workshops and brainstorming. Not for formal BPMN modeling.

Whimsical

Clean, minimal, and fast. Whimsical is great for flowcharts and wireframes. It has no specific BPMN support, but some teams use it for simple process flows. If your processes don't need BPMN notation, Whimsical's simplicity is a feature.

Best for: Simple flowcharts and wireframes. No BPMN support.

Open Source

bpmn.io

The open-source BPMN editor built by Camunda. bpmn.io runs in the browser, supports real BPMN 2.0, and is completely free. It's the engine behind many other BPMN tools. Great for learning, quick modeling, and embedding in your own applications.

Best for: Learning BPMN, quick modeling, developers building custom tools.

Which One Should You Pick?

It depends on what you actually need:

If you need...	Look at
Enterprise governance & compliance	ARIS, Signavio, iGrafx
Process automation (code)	Camunda
Process mining	Celonis, Signavio
Free BPMN learning	Crismo, bpmn.io, Bizagi
Quick informal diagrams	draw.io, Lucidchart
Workshop collaboration	Miro
Full standards (BPMN+DMN+CMMN)	Trisotech

Still not sure? Take our free tool finder quiz - 5 questions, 2 minutes, and you'll get a personalized recommendation with scores and a PDF report you can share with your team.

One More Thing

We're building Crismo - an AI-native BPMN modeling tool designed for teams that want proper BPMN without the enterprise complexity. Real-time collaboration, AI-assisted modeling, and BPMN 2.0 compliance built in. If you're tired of choosing between "easy but not real BPMN" and "real BPMN but painful" - check it out.

All tool profiles are maintained at ProcessCamp and updated regularly. Found something outdated? Let us know.