Process map symbols, explained. The dozen shapes actually worth knowing.

The short answer. Six shapes cover almost everything you will ever draw.

A process map is only useful if someone who was not in the room when it was drawn can pick it up and read it correctly. That is the entire reason the shapes are standardised rather than invented fresh for every diagram: a rectangle always means an activity, a diamond always means a decision, and once you know that, you can read a map from any team, in any business, without a briefing.

The core set most businesses actually use is small:

Two more turn up often enough to be worth knowing: a document shape (a rectangle with a wavy bottom edge) for a report or form, and a rectangle with double-lined sides for a predefined process, a step that is itself a fully mapped sub-process documented elsewhere. Beyond those eight, most maps are inventing shapes rather than clarifying anything.

How it works in practice. Reading a map by shape before you read a single label.

The current international reference for these symbols is ISO 5807, the standard covering documentation symbols for data and system flowcharts, first published in 1985 and still the version most style guides point back to. It formalised conventions that had already been in informal use since the 1960s, when ANSI's early flowcharting standards set out broadly the same terminator, process and decision shapes still used today.

That history matters more than it looks, because it explains why the symbols have survived essentially unchanged for sixty years while the software used to draw them has been replaced several times over. A shape's meaning is not tied to any particular tool. A diamond drawn on a whiteboard in 1975 and a diamond dropped into Lucidchart today carry the identical instruction: a decision sits here, and the process branches. That portability, readable on paper, on a whiteboard, or in any diagramming tool, is the entire point of standardising the shapes in the first place, rather than leaving each team to invent its own.

A separate, newer notation exists for processes that cross more than one department: BPMN, Business Process Model and Notation, maintained by the Object Management Group since its first release in 2011 and now on version 2.0.2. BPMN keeps the same basic shape logic (a rounded terminator, a rectangle for a task, a diamond for a gateway) but adds pools and swimlanes, horizontal or vertical bands that show which team or role owns each step. That single addition is why workflow diagrams built for cross-team handoffs almost always use swimlanes, while a single department's internal process rarely needs them.

In practice, most businesses do not pick one standard and follow it exactly. They borrow the handful of shapes that carry real information (terminator, activity, decision, flow) and add swimlanes only once a process genuinely crosses a handoff between teams. That pragmatic mix is what process mapping looks like on the ground, and it is deliberately closer to ISO 5807's simplicity than to BPMN's full notation, which was built for enterprise software modelling rather than a founder documenting how refunds get approved.

What good looks like. Consistent shapes, one meaning each, no invented symbols.

A well-drawn process map reads left to right or top to bottom in a single, unbroken line, with branches clearly labelled and every path eventually reaching a terminator. Each shape appears with exactly one meaning throughout the whole map: if a rectangle means "activity" on the first row, it means the same thing on the last row, and nothing else on the map competes for that shape.

Swimlanes earn their place only when a process genuinely crosses ownership. A single support agent handling a refund from start to finish does not need a swimlane; the moment that refund needs sign-off from a manager in a different team, a lane for each role makes the handoff visible in a way a single unbroken flowchart cannot. Adding swimlanes to a process that never actually changes hands just adds a visual layer with nothing underneath it, which is as much a fault as leaving them out when they are needed.

Colour is worth using sparingly, if at all: one colour to flag a step that is manual versus automated, or a lane that belongs to an external partner rather than an internal team, is useful. Colour used purely to make the map look finished, with no consistent rule behind it, tends to slow a reader down rather than help them.

A worked example. Five symbols map a refund request end to end.

Take a common founder-led process: a customer refund request. Mapped with the core symbols, it runs like this. A terminator oval marks "Refund request received". An arrow leads to a rectangle: "Support agent checks order against the refund policy". That leads to a diamond: "Within policy?" A "no" arrow leads to a rectangle, "Agent explains the policy and offers an alternative", ending at a terminator. A "yes" arrow leads to a second diamond, "Under £100?" A "yes" arrow leads straight to a rectangle, "Agent processes refund directly", ending at a terminator. A "no" arrow leads to a rectangle, "Escalate to manager for approval", then a document shape, "Manager signs off in writing", then the same processing rectangle and terminator.

Nine shapes, one page, and a support agent who has never seen the map before can follow it correctly on the first read. That is the actual test of whether the symbols were used correctly: not whether the diagram looks polished, but whether someone outside the process can execute it without asking a follow-up question.

Pitfalls to avoid. The mistakes that turn a map into a puzzle.

The most common fault is a decision diamond with an unlabelled or single exit arrow. A diamond represents a question, and a question needs at least two clearly labelled answers leading somewhere different; a diamond with one exit is really just a rectangle wearing the wrong shape.

The second is a map with no terminator at either end, so a reader cannot tell where the process actually begins or where it is genuinely finished versus merely paused. The third is mixing custom, invented shapes into an otherwise standard map: a cloud for "waiting", a star for "urgent". They feel expressive in the moment and unreadable to anyone who joins the business six months later.

The fourth, and the one that causes the most rework, is drawing the map from memory of how the process is supposed to work rather than watching or asking how it actually runs today. A beautifully symbol-correct map of the wrong process is still the wrong process; get the sequence of real steps right first, then apply the shapes, not the other way round.