BPMN Best Practices: Modeling Rules That Actually Matter

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.