BPMNBehaviour diagrams

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.

August 5, 202611 min readBPMN 2.04 of 7

The short answer

A first diagram belongs in one pool. That removes the notation's hardest rule and leaves the process itself as the only thing to get right.
Loop a rework path back to the task that gets redone, not to the gateway that caught the problem. Both are legal; only one reads correctly.
A second pool is for a participant you cannot direct - a customer, a supplier, a payment provider. Your own departments are lanes.
One page, about fifteen flow objects. Past that a reader stops tracing paths and starts hunting for the box with their name on it.

A BPMN collaboration for employee onboarding. In the People team pool, an offer accepted start event leads to a prepare contract task, then a parallel gateway splitting into a book induction task and a request accounts task. The request accounts task sends a message to the IT service desk pool below, which replies with credentials to an accounts ready intermediate message event. Both branches join at a second parallel gateway, ending at a ready to start end event. — Employee onboarding across two participants. Everything the people team does is sequence flow inside their pool; everything crossing to the service desk is a message. That split is the first rule worth internalising, and it is visible here before a word of explanation.

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#

A BPMN expense approval process in one Finance pool. An expense submitted start event leads to a check receipts task, then an exclusive gateway asking whether the claim is complete. The yes branch leads to an approve expense task and a reimbursed end event. The no branch leads to a request missing receipt task, which flows back into the check receipts task. — The flow back into Check receipts is what makes this a real process. Without it the diagram claims every expense claim arrives complete, which no finance team has ever observed.

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 BPMN support process in one Support desk pool. A ticket raised start event leads to a triage ticket task, then an exclusive gateway on priority. The high branch leads to a page on-call task, then a fifteen minute timer intermediate event, then an escalate to manager task. The normal branch leads to a queue for team task and a ticket closed end event. — An intermediate timer in the high-priority path: the process waits fifteen minutes, and if it is still here, it escalates. Time is a first-class citizen in BPMN, which is the single biggest thing it has over a flowchart.

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 BPMN subscription renewal collaboration. In the Billing pool, a renewal date timer start event leads to a charge card task, a result received intermediate message event, then an exclusive gateway asking whether payment succeeded. The yes branch leads to an extend subscription task and a subscription active end event; the no branch leads to a start dunning task and a subscription lapsed end event. The Card processor pool below is collapsed and exchanges two message flows with the Billing pool. — Two symbols carry this diagram: a clock in the start event, meaning nobody triggered this and a date did, and an empty second pool, meaning the card processor is a participant whose internals are none of our business.

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#

A BPMN goods return process in one Returns pool. A return received start event leads to an inspect item task, then an inclusive gateway asking what is owed. One branch issues a refund, the other ships a replacement, and either or both may run. A second inclusive gateway joins them, leading to a notify customer task and a return closed end event. — An inclusive gateway: refund, replacement, or both, depending on what the inspection found. The matching join waits for exactly the branches that were taken, which is the behaviour a pair of exclusive gateways cannot express.

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.

ShareX LinkedIn

↑ Back to top All BPMN articles →

In this series