BPMN examples
Five processes drawn end to end - onboarding, expenses, support tickets, subscription renewal and returns - each chosen because it forces one thing a symbol table cannot teach: a second participant, a rework loop, a deadline, a black box, or a branch that is genuinely both.
11 min readBPMN 2.04 of 6
01How to read the five
Every diagram below is a complete process rather than a fragment, and each one is the smallest process that still forces one idea you cannot get from a symbol table. Read them in order and they build; skip to the one whose shape matches your problem and they stand alone.
- Onboarding - two participants, and why the boundary between them changes what you are allowed to draw.
- Expenses - a rework loop, which almost every real process has and almost no first diagram shows.
- Support tickets - a deadline that changes the path.
- Subscription renewal - a timer start event, and a participant whose internals are deliberately not modelled.
- Returns - the inclusive gateway, on one of the few processes where it is genuinely the right answer.
If a symbol in any of them is unfamiliar, the symbol reference indexes every mark on this page.
021. Onboarding, across two participants
The figure at the top of this article. A new hire accepts, the people team prepares a contract, and then two things happen at once: an induction gets booked and accounts get requested from a service desk the people team does not run.
The parallel gateway is doing real work here. It does not say "these could happen in either order" - it says both paths always run, and the join waits for both. If the induction is booked in a minute and the accounts take two days, the process sits at that join for two days, which is exactly the fact a diagram like this exists to make visible.
032. Expenses, and the loop nobody draws
First drafts of approval processes are almost always straight lines: submit, check, approve, pay. Real ones bounce. Something is missing, somebody is asked for it, and the check happens again - and until that loop is on the page, the diagram is describing a process that does not exist.
Two details are worth copying. The return flow lands on Check receipts, not on the gateway: looping into the gateway is legal and reads as an unconditional cycle to anybody seeing it for the first time. And the corrective task sits below the gateway rather than below the approval, so its return runs back along an empty lane instead of crossing two live edges.
043. Support tickets, and a deadline
A flowchart can show a decision. It cannot show that something happens because a quarter of an hour passed. That is the gap BPMN's event set closes, and it is why a support process is one of the better arguments for the notation.
The timer here is an intermediate event in the flow, which makes the process wait. Two neighbouring shapes mean different things and are worth keeping straight: a timer on the boundary of an activity interrupts that activity when it fires, and an event-based gateway races the timer against something arriving, so whichever happens first wins. Which one you want depends on whether the work in progress should be abandoned.
054. Subscription renewal, against a black box
A timer start event answers a question that trips up most first models: what starts this process? Not every process is started by a person or a message. A renewal starts because a date arrived, and saying so removes an imaginary actor from the diagram.
The collapsed pool is the other lesson. It would be easy to draw the processor's internal steps - authorise, capture, settle - and every one of them would be a guess about somebody else's system that ages badly. An empty pool with two message flows states precisely what is known and precisely what is not, and it stays true when the provider changes their implementation.
065. Returns, and a branch that is genuinely both
Most branches are exclusive - one path out - and most of the rest are parallel, where every path always runs. The inclusive gateway is for the case in between, and returns are a genuine instance of it: a damaged item might warrant a refund, a replacement, or a partial refund plus a replacement, and which combination applies is decided by the inspection.
This is also the gateway most likely to cause trouble, and the reason is on the right of the figure. The join has to wait for exactly the branches the split activated - no more, or it deadlocks waiting for a path that never carried a token. Every split needs its matching join, and adding a shortcut edge around one is how a process quietly stops completing.
In one line each
- 01Sequence flow inside a pool, message flow between pools. A second pool is a claim about who you do not control.
- 02A process with no rework loop is usually a process nobody has checked against reality.
- 03Loop back to the task that repeats, not to the gateway that noticed.
- 04A timer start event says a date began this, not a person.
- 05An empty pool is knowledge, not omission: these messages are known, the internals are not.
- 06Inclusive gateways must be balanced - every split needs its join, or the process hangs.
- 07One page, roughly fifteen flow objects. Past that, collapse a subprocess.
The order to put these down in is in how to draw a BPMN diagram, and every mark used above is indexed in the BPMN symbol reference.
07Common questions
What is a good first BPMN diagram to draw?
A process you personally run, with one pool, one start event, four or five tasks, one exclusive gateway and two end events. Keeping it inside a single pool removes the hardest rule in the notation - that sequence flow cannot cross a pool boundary - and two named end events force the useful question of how the process can finish, which is the one most first diagrams never ask.
How do you show a rework loop in BPMN?
Draw a sequence flow from the end of the corrective task back to the task that has to be repeated, not back to the gateway that detected the problem. Both are legal, but looping into the gateway reads as an unconditional cycle to anybody who has not drawn one before, while looping into the task shows exactly what work is redone.
How do you model a deadline in BPMN?
With a timer event, and which one depends on what should happen. A timer attached to the boundary of an activity interrupts it when the time is up and diverts the token down an escape path. A timer as an intermediate event in a sequence flow simply makes the process wait. If the deadline races against something else arriving, an event-based gateway is the right shape.
Does every BPMN diagram need more than one pool?
No, and most should not have one. A second pool is worth its cost only when the diagram genuinely needs to show a participant you do not control and cannot direct - a customer, a supplier, a payment provider. Splitting your own departments into separate pools is almost always wrong; those are lanes in one pool, because sequence flow has to be able to run between them.
How much detail belongs in one BPMN diagram?
One page, and roughly fifteen flow objects. Past that, readers stop tracing paths and start scanning for the box with their name on it. When a process genuinely is larger, the answer is a collapsed subprocess that has its own diagram, which keeps every picture at a scale a person can actually hold in their head.
Related reading