Symbols at a glance
The dozen symbols that carry a business process
Everything below is standard BPMN 2.0. If you can read these shapes, you can read almost any process diagram, including the ones patchley drafts from a conversation. Only the control-step marking is a patchley addition.
Events
Events: where a case begins, pauses and ends
What triggers the case
One thin circle, named after the trigger.
Waiting for a message or a date
Message: documents arrive. Timer: a deadline passes.
Which result the case reached
One thick circle per outcome, named as a result.
Events are the circles. They do not describe work; they describe that something has happened. A start event opens a case: "Claim reported", "Application received". Name it after the trigger, not "Start".
An intermediate event sits in the middle of the flow and makes the process wait or react. The two you will meet most are the message event (the process waits for something to arrive, such as the customer's documents) and the timer event (a deadline or a waiting period). Both are the double circle, with an envelope or a clock inside.
An end event closes the case. A process may have several: "Payout received" and "Decline received" are two results, and the diagram should show which path leads to which. An end is never a task in disguise: "Send decline letter" is work; the end is "Decline received".
Tasks and subprocess
Tasks: one unit of work, one role, verb plus object
A task is the rounded rectangle, and it carries most of the meaning in a diagram. Three habits keep tasks readable. Name every task as verb plus object: "Register claim", not "Claim". One task is performed by one role and sits in that role's lane; if two roles share it, it is usually two tasks with a hand-over. And a task is a unit of work, not a keystroke: "Enter customer data" is a task, "Click save" is not.
When a diagram stops fitting on one screen, the answer is a subprocess: a task that stands for a whole process of its own, drawn in a separate diagram. "Check coverage" can be one task in the claims diagram and a full diagram for the underwriting team. The parent stays readable, and each team owns its part. patchley draws a process landscape from several such diagrams.
Task one diagram
- One role, one lane
- Verb plus object as the name
- May be marked as a control step
- May name the system and the documents it uses
Subprocess own diagram
- A step that opens into a second diagram
- Keeps the parent diagram on one screen
- Has its own start and end events
- Often owned by a different team
Gateways
Gateways: where the process decides
A gateway is the diamond. It does no work and decides nothing itself; the decision was made in the task before it. The gateway shows how the flow splits and, later, how it joins. Below, "Check coverage" is the work and "Covered?" is the gateway that routes the case.
| XOR · exclusive | AND · parallel | OR · inclusive | |
|---|---|---|---|
| Symbol | Diamond with × | Diamond with + | Diamond with ○ |
| Reads as | A question with exactly one answer: "Covered?" yes or no. | No question. Everything after it runs at the same time. | A question with several possible answers that can all be true. |
| Paths that continue | Exactly one | All of them | One or more, depending on the conditions |
| Join | Paths simply merge. | A second + diamond waits for every path. | A second ○ diamond waits for every path taken. |
| Example | Covered? → approve payout or decline | Order confirmed → invoice and picking start together | Which checks apply? → credit check, sanctions check, or both |
"Covered?", "Amount above limit?", "Complete?" with every outgoing arrow labelled with an answer. A gateway without a question is the most common reason a diagram cannot be signed off.
Pools and lanes
Pools and lanes: who does what, and who talks to whom
One participant
Your organisation, the customer, a supplier. Own start, own end, own steps.
One role inside the pool
Claims handler, underwriter, management, a system, an AI agent.
What crosses between pools
Dashed arrows for forms, letters and answers.
A pool is one participant in the process: your organisation, the customer, a supplier. Inside a pool, lanes divide the work by role: claims handler, underwriter, management. Every task sits in the lane of the role that performs it, so the diagram answers "who does what" without an extra word; the lane is the R of a RACI.
Lanes should be roles, not departments. "Underwriter" is a role; "Underwriting department" may contain three roles and hide the hand-overs between them. A system or an AI agent can have a lane of its own when it performs steps rather than merely being used; see processes before AI agents.
Between pools there are no sequence flows. A customer and an insurer do not share one sequence of steps; they exchange message flows: the claim form, the request for documents, the decision letter. Each pool keeps its own start and end; the dashed arrows show what crosses the boundary.
Data objects and systems
Data objects and systems: what a step needs and where it works
Who does what in which order is half a specification. The other half is what each step needs, what it produces and in which system it happens: the part an automation team or an AI agent reads most closely.
Data objects documents and records
- The document shape next to a task, joined by a dotted line
- Inputs: the claim form, the policy file, the invoice
- Outputs: the decision letter, the purchase order
- Name the object, not the format
Systems where the work happens
- The application a task uses: CRM, ERP, claims system, email
- Shown as a label on the task or as a lane when the system acts on its own
- In patchley, systems and documents are captured per step from the conversation
A control step is a task whose purpose is to check or approve: a four-eyes approval, a plausibility check, a compliance review. Mark them. They are the steps an audit asks about and the steps an AI agent must not skip.
The control step is the built-in marker, in blue. Beyond it, your organisation decides which kinds of steps get highlighted, and how. Under Processes → Process settings it defines up to five markers of its own, each with a name, a criterion in plain words (manual steps, media breaks, customer contact, steps an AI agent could take over), what it applies to (tasks, decisions, events) and a colour. Markers are switched on per process. When patchley builds the diagram, it marks the steps that match; they show as fill colours with a legend, on the slides and as a yes/no column in the XLSX export.
Common mistakes
The mistakes that make a diagram hard to agree on
None of these break the notation. All of them make people argue about the picture instead of the process.
Gateway without a question
A diamond with two unlabelled arrows. Nobody can say which case goes where, so nobody can confirm the diagram.
Lanes by department instead of role
"Operations" as a lane hides three hand-overs inside one box. Use the roles that actually pass the case along.
No end event, or one for everything
A flow that just stops, or ten outcomes funnelled into one "End". Name each result and give it its own end.
Too many symbols
Event subtypes, markers and annotations on every element. Readers stop reading. A dozen symbols are enough.
Text instead of structure
A task called "Check and, if necessary, escalate to management, otherwise approve" is a gateway and three tasks pretending to be one.
Exceptions left out
The happy path only. Missing documents, rejected invoices and withdrawn applications are where most of the work and the controls are.
Checklist
Before people sign off a diagram
Eight questions for the process owner before the As-Is counts as agreed. In patchley the analyst proposes changes and every change is shown before it lands; this list is what to look for when you decide.
One start, named after the trigger
"Claim reported", not "Start". Two triggers are two start events or two processes.
Every task is verb plus object, in the lane of the role that does it
Read each task with its lane in front of it: "Claims handler: Register claim."
Every gateway is a question with labelled answers
And the task before it is where the answer is actually found.
Every parallel split has a join
Otherwise the process never finishes on paper and cannot be automated.
Each distinct result has its own named end
Paid, declined, withdrawn, escalated: the people know the outcomes; the diagram should too.
Control steps are marked
Approvals, four-eyes checks and compliance reviews are visible, so nobody designs them away later.
Systems and documents are named where they matter
Not on every task, but wherever a record or a file decides how a step runs.
It fits on one screen, or it has subprocesses
If the reader has to scroll twice, split it.
A diagram is ready to sign off when every person in the room can point at their lane and say "yes, that is what I do, and that is where I hand over".