BPMN 2.0 defines more than a hundred elements. Compensation events, escalation boundaries, ad-hoc sub-processes, transactions. I have drawn several hundred diagrams for a Europe-based transformation programme and I have used maybe eight shapes with any regularity. Not because the rest are useless, but because a diagram has an audience, and the audience is usually an operations lead who has never opened the spec.
The eight
Pool and lane. The pool is the process boundary. Lanes are who acts inside it. If a step cannot be placed in a lane, you have found an owner nobody has assigned yet, which is usually the most valuable thing the diagram will tell you.
Start and end event. Thin circle in, thick circle out. Give both a label. "Claim submitted" and "Claim settled" say more about scope than any paragraph in the document.
Task. A rounded rectangle, labelled verb-plus-object. Verify documents. Approve invoice. Not "verification" and never "invoice process" — a noun on a task is a step that has not been thought through yet.
Exclusive gateway. The diamond with the X. One path out, chosen by a condition. Label the diamond as a question and label every outgoing arrow with an answer. An unlabelled gateway is the single most common defect I see in other people's diagrams.
Parallel gateway. The diamond with the plus. Everything runs, and the process waits for all of it. Useful the moment somebody says "meanwhile, finance is also checking."
Message flow. The dashed arrow between pools. This is how you show that another organisation is involved without pretending you know what happens inside their process.
Timer event. The clock. Every escalation rule and every SLA lives here. "If not approved within 48 hours, route to the regional manager" is a timer boundary event, not a footnote.
Data object or data store. Where the record comes from and where it lands. Optional in a workshop, essential when the diagram becomes a spec for a developer.
The discipline is in the labels
Notation errors rarely break a diagram. Vague labels always do. Three rules I hold to:
- Every task starts with a verb in the imperative.
- Every gateway is phrased as a closed question with all answers on the arrows.
- Every end event names a business outcome, not "end". A process with four distinct outcomes gets four end events, and now the failure paths are visible instead of implied.
As-is before to-be, always
The temptation on a transformation project is to skip straight to the future state, because the current state is a mess and everybody already knows it. Skip it and you will design around a workaround that existed for a reason. Somewhere in the mess is a manual check that catches a failure mode nobody wrote down.
Model the as-is until the people who run it agree it is accurate — including the parts they are not proud of. Then draw the to-be beside it and mark what changed: steps removed, steps automated, steps whose owner moved. That comparison is what a steering committee actually wants to look at.
Where the spec earns its keep
Reach for the rarer elements when the process genuinely has that shape. Sub-processes when a diagram no longer fits on a page and a chunk of it is reusable. Error boundary events when a step can fail in a way that needs its own handling path. Signal events when one process broadcasts to several.
But reach for them because the process demands it, not because the diagram looks too simple. A simple diagram of a simple process is the goal, not a shortcoming.