Your diagram has 47 tasks and nobody can read it. The labels are vague. The flow goes in circles. Here are the rules that separate readable process models from expensive wallpaper.
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.
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.
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?
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.
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.
Tasks represent actions - someone has to do something. Your labels should reflect that. Compare these two names for the same task:
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.
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.
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:
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.
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:
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.
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.
Apply these rules and your processes stop being diagrams. They become tools - readable, maintainable, and useful to everyone in the organization.
Interactive diagram coming soon
This will be a live Crismo canvas you can explore and edit
Model this process yourself
Open a free diagram in Crismo and build what you just learned. No signup needed.
Open in Crismo →