Business Process Model and Notation defines 116 elements. Version 1.0 had 48, and the count grew as the standard tried to cover everything anyone might want to draw.
Nobody uses 116 elements. A study of 120 real BPMN diagrams found that less than 20 percent of the vocabulary was used regularly, that the average diagram contained nine distinct constructs, and that two diagrams of that complexity typically had only four or five constructs in common. Some elements did not appear in a single model the researchers looked at.
That finding is usually reported as a criticism of the standard. It reads better as a set of instructions. There are nine shapes worth learning, they take about ten minutes, and they cover almost everything a business will ever need to draw.
Who owns it, and why that is the interesting part
The notation is maintained by the Object Management Group, the same standards body behind UML. BPMN 2.0 arrived in January 2011, the current revision is 2.0.2, and the specification is published as the international standard ISO/IEC 19510.
The ownership matters for one practical reason. A diagram drawn in BPMN can be read by a consultant, a developer, an auditor, a software vendor and the person who will replace you, none of whom need you in the room to interpret it. That is the entire value proposition of a notation standard, and it is why a slightly awkward standard beats a beautiful private convention.
The specification is also explicit about what it does not cover: organisational structures, functional breakdowns, and data models are outside its scope, and it is not a data flow diagram. It draws how work moves, not how a company is arranged or how information is stored. Knowing the boundary keeps diagrams from turning into everything-maps that answer no question well.
The four families
Every shape belongs to one of four groups, and knowing the groups makes the rest obvious.
Flow objects are the things that happen: events (circles), activities (rounded rectangles), and gateways (diamonds). These carry the actual work.
Connecting objects are the lines: sequence flow for order within one participant, message flow for anything crossing between participants, and association for attaching a note.
Swimlanes are pools and lanes, which say who owns what.
Artifacts are the annotations and data objects that add context without changing the flow.
That is the whole architecture of the notation. Everything else is a variant within one of those four families.
The three shapes that carry the meaning
Circles, rectangles and diamonds. Everything else is decoration on top of these.
A circle is an event. Something happened. A thin circle starts a process, a thick one ends it. The useful discipline is that a start event should name the trigger: not “process begins” but “quote request arrives” or “invoice is 30 days overdue”. A process without a named trigger usually turns out to be several processes wearing one name.
A rounded rectangle is a task. Somebody or something does work. The naming convention is verb plus object, in the words the business actually uses. “Price the job” beats “pricing subprocess”. If a task needs a paragraph to explain, it is more than one task.
A diamond is a gateway. The path splits or rejoins. This is where most of the useful argument happens in a mapping session, because a gateway forces the question of what decides, and the answer is frequently that nobody has written it down.
Three gateway types cover nearly everything:
- Exclusive (a diamond with an X): one path or the other, never both. The refund is either under the manager’s limit or over it.
- Parallel (a diamond with a plus): both paths run, and both must finish before the process continues. The credit check and the site survey happen at the same time.
- Event-based (a diamond with a circle inside): whichever thing happens first decides the path. The customer either confirms within five days or the quote expires.
That third one is worth knowing even though it is less common, because it is the only clean way to draw a wait with a deadline, and undrawn waits with deadlines are a reliable source of trouble.
Pools and lanes change the conversation
The swimlane is the shape that most changes how a room talks about its own work.
A pool is a participant you do not control from inside this process: the customer, the supplier, the bank, the regulator. A lane is a subdivision inside your own pool, usually a role rather than a named person: sales, the shop, the office, the owner.
One rule follows from that and it is the whole reason to bother. Anything crossing between pools is a message. Anything moving inside a pool is sequence flow. Draw it that way and every boundary crossing becomes visible on the page, which matters because boundary crossings are where cases sit and where information falls out.
Lanes are also what make a diagram legible as a permission model later. A step sitting in the office lane is owned by the office, which is the same statement as saying what a system running that step is allowed to touch. The drawing and the build end up describing the same boundary.
Why a standard beats a photo of a whiteboard
The whiteboard photo is not wrong. It is just unreadable six weeks later by anyone who was not standing there.
A standard notation buys four things:
It transfers. A new hire, a bookkeeper, a software vendor and an auditor all read the same shapes. Nobody has to be walked through the private meaning of a hexagon.
It is testable. Standard shapes have rules. A gateway with one outgoing path is a mistake. A branch with no destination is a mistake. A drawing in a proper notation can be checked; a sketch can only be admired.
It survives people. The person who drew it will eventually leave. The diagram keeps working, which is precisely what the private convention does not do.
It carries into software. BPMN 2.0 includes an XML form of the diagram, which means a drawing can be handed to tools rather than retyped from a picture. That is a real advantage over a photograph, with a caveat covered in the piece on tool diagrams.
When drawing one is overkill
The honest counterweight, because notation enthusiasm is a real failure mode and a room full of swimlanes has killed more improvement projects than it has helped.
Skip the diagram when the process is genuinely three steps with no branches, when one person does the whole thing end to end, or when it runs four times a year and nobody is confused. A written checklist is the better artifact in all three cases, and it will actually be used.
Drawing earns its keep in three situations: work crosses between people or systems, the same case can take materially different routes, or something is about to be built on top of the process. The third one is not optional. A build without an agreed drawing is a build where the process is decided by whoever writes the code, one function at a time.
There is also a size test that works better than a step count. If two people who both do the work describe it differently, draw it. If they describe it the same way, a checklist is fine and the disagreement was never the problem.
The part worth carrying out the door
The notation is larger than anyone needs, which is a solved problem: learn nine shapes and ignore the other hundred.
Circles for what happens, rectangles for what gets done, diamonds for where it splits. Pools for participants you do not control, lanes for roles you do. Solid lines inside a pool, dashed lines crossing between them. Notes where a shape cannot carry the meaning.
Ten minutes of vocabulary, one page of drawing, and the result is something other people can act on without you in the room. That is a low price for the only artifact that reliably survives a change of staff, a change of software, and a change of mind.