BPMN: mapping what actually happens

BPMN (Business Process Model and Notation) is a standardized way to draw a process as a diagram. It was developed by the Object Management Group and is an ISO standard (ISO/IEC 19510). The shapes are fixed, so anyone familiar with BPMN can read a diagram without needing it explained.

The core shapes:

For a full reference: Camunda BPMN notation guide is a good starting point, less dense than the full specification.

Why BPMN rather than a plain flowchart

A flowchart describes steps. BPMN describes who does each step and whether it's a human action or a system action.

That distinction matters as soon as more than one person is involved. In a membership signup flow, the member fills a form, the payment system processes the charge, and the platform grants access — three different participants. A plain flowchart flattens them. BPMN puts each in their own swim lane so the responsibility is unambiguous.

BPMN also handles decision branches explicitly. Every diamond gateway is a question with named outcomes. Drawing those out forces you to answer: what happens when payment fails? What if the member doesn't have an account yet? Those questions surface in the diagram, not in a support ticket six months later.

Where BPMN pays off for organisations

New staff understand processes without a walkthrough. A BPMN diagram shows who does what, what the system handles automatically, and what happens when something goes wrong. New team members can orient themselves from the diagram before asking questions.

Process gaps become visible. The act of drawing the diagram surfaces unanswered questions. Organisations that run on undocumented tribal knowledge often discover, on paper, that steps they assumed were handled aren't accounted for anywhere.

Different teams read the same thing. Operations, IT, and management can all read the same BPMN diagram. There's no translation between what was implemented, what was spec'd, and what was communicated to users. The notation is standardised so it doesn't belong to any one team's vocabulary.

Processes that span systems get a clear boundary. When your workflow touches an external service — a payment provider, an email platform, an identity system — BPMN makes the boundary explicit. Which step calls the external service? What happens if it fails? Where does your process resume? Prose descriptions of these flows get unwieldy; a diagram keeps it readable.

Documentation stays honest. When you change a process in a BPMN diagram, broken connections are immediately visible. That makes partial updates hard to miss. Prose documents can absorb changes silently; a BPMN file can't.

Getting started

You don't need software to start. Sketch the process on paper first:

1. Write down every step as a box.
2. Label each box: is it something a person does, or something a system does automatically?
3. Add diamonds wherever a decision is made.
4. Group steps by who's responsible — those groups become swim lanes.
5. Add arrows to connect everything, and label the branches on each diamond.

Once you have the sketch, bpmn.io is a free browser-based tool to draw a clean version. Camunda Modeler is the desktop option.

UML: describing how things are structured

UML (Unified Modeling Language) is a broader standard that covers both process diagrams and structural diagrams. The full UML specification includes over a dozen diagram types. In practice, most organisations use a small subset.

The two most immediately useful:

Class / entity diagrams — show how your data objects relate to each other. For a community platform: a Community has many Members, a Member can have a Membership, a Membership is linked to a Plan. Drawing this out clarifies what data you're actually managing and where the relationships sit.

Use case diagrams — show what actors (people or systems) can do within a system, without describing how. Each use case is an action the system supports; lines connect actors to the actions available to them. A community platform use case diagram might show that a Member can register for events and submit forms, while an Admin can additionally create events, manage members, and configure plugins.

Use case diagrams are deliberately high-level. They don't capture sequence or decision logic — that's not their job. Their value is in agreeing on scope: what does the system do, who can do it, and are there any actions that apply to multiple roles.

Tying use cases to BPMN

Use cases and BPMN diagrams work well together at different levels of detail.

A use case identifies that something happens — "Admin invites a member." The BPMN diagram for that same process shows how it happens: the admin navigates to the members section, enters email addresses, clicks send, the system saves the invitations and sends emails, the invited person receives the email, clicks the link, and accepts or declines.

A practical approach is to start with a use case diagram to agree on what the system needs to support, then draw a BPMN diagram for each use case that has meaningful process complexity. Not every use case needs a BPMN — "member views their profile" probably doesn't. But "member subscribes to a paid plan" has enough branching (payment success, payment failure, grace period, access grant) that a diagram earns its keep.

The two together give you two levels of documentation: the use case diagram as a map of what the system does, and the BPMN diagrams as the detail behind each significant flow.

Most teams don't need a dedicated UML tool. Mermaid supports use case and entity diagrams in plain text that renders directly inside Markdown files.

A practical starting point

If you're running an organisation on YeahApp and want to start documenting your processes, pick one workflow that causes confusion or relies on one person knowing it. That's usually a good candidate.

Draw the process in BPMN — even a rough sketch on paper. Answer the gateway questions: what are the branches, what happens in each case? Then write the prose doc from the diagram. The steps should match.

That combination — a BPMN diagram and a plain-language document written from it — is more durable than either one alone.

Further reading

• Camunda BPMN reference — practical notation guide with examples
• BPMN 2.0 specification — the full OMG standard
• bpmn.io — free browser-based BPMN viewer and editor
• UML 2.5 specification — the full UML standard
• Mermaid documentation — text-based diagramming that renders in Markdown