Process Map

A process map is a diagram of the steps, decisions, handoffs and systems in a process, drawn in the order they happen. ASQ describes the flowchart as a common type of process map and lists it among the seven basic quality tools.

Use a process map to agree on how work happens, see who does what, and choose where to investigate or improve the flow. A useful map makes its start, outcomes, responsibilities and important exceptions clear.

In a root cause analysis, it answers a narrower question than “why did this fail?”: where in the flow does it fail? Knowing the step, decision or handoff focuses the search for causes.

This is a basic flowchart arranged in swimlanes, not a formal UML activity diagram or BPMN model. The rectangles show actions, the diamond asks a question, and the labelled paths show what happens next. The Person and System lanes show responsibility. Similar-looking shapes in formal notations can have different meanings.

Which process-mapping notation should you use?

A process map describes what you are trying to understand; a notation defines how you draw it. Start with the simplest notation your readers can interpret consistently.

Approach	What it adds	Choose it when
Basic flowchart	Steps, decisions and connected paths using a small symbol set	A team needs a shared account of a task, workflow or problem area
Swimlane layout	Rows or columns grouping work by person, team or system	Handoffs and responsibility are central to the question
UML activity diagram	Defined rules for actions, control flow, decisions, parallel work and activity partitions	Product and engineering teams need a precise account of behavior within a wider UML model
BPMN	Defined rules for tasks, events, gateways and collaboration between participants	A business workflow needs to express triggers, messages, exceptions or parallel paths precisely

Swimlanes are a layout convention, not a competing standard: they can organize a simple flowchart, UML activity partitions or lanes within a BPMN pool. Their presence alone does not identify the notation.

UML and BPMN are standards maintained by the Object Management Group. A workshop sketch does not need their full vocabulary. Conversely, drawing familiar shapes does not make a sketch a valid executable workflow; execution depends on the model and the target engine’s supported elements and configuration.

Common process-map symbols and their meanings

These are common flowchart conventions, also reflected in Mermaid’s flowchart documentation. They are a starting legend, not a universal key for every modeling language.

Shape	Common meaning	How to use it
Oval or pill-shaped terminator	Start or end of the mapped process	Name the trigger or outcome, such as “Form opened” or “Company details saved”
Rectangle	Action or process step	Use a verb and object: “Validate company details”
Diamond	Decision that routes the flow	Ask a question such as “Complete?” and label outgoing paths “Yes” and “No” or with other clear conditions
Arrow	Direction of the flow	Connect the actual next steps; label conditions instead of leaving the reader to guess
Parallelogram	Input or output	Identify information received or produced, such as company details entered by a customer
Rectangle with a wavy bottom	Document	Name the document, such as an invoice or approval form
Cylinder	Data store or database	Show stored information; use a separate action for reading or saving it
Lane or partition	Grouping by responsibility or another stated category	Put each action in the relevant lane and make cross-lane handoffs visible

You can begin with just start/end markers, rectangles, diamonds and arrows. Add other symbols when the distinction helps the reader. Include a legend for local conventions, keep labels specific, and separate annotations about evidence or uncertainty from the process steps themselves.

How UML activity symbols differ

In UML activity diagrams, an action is usually a rounded rectangle; rounding does not mean “start or end.” A filled circle marks an initial node. A filled circle inside an outer circle marks an activity final node, while a circle containing an X is a flow final node: ending one flow differs from terminating the whole activity.

Diamonds can represent decisions or merges. A merge brings alternative paths together; it does not synchronize parallel work. Thick bars represent forks and joins for parallel flows. Label decision edges with conditions, often written as guards such as [complete] and [incomplete]. Activity partitions can group actions by responsibility.

How BPMN symbols differ

In BPMN, rounded rectangles are tasks or activities, circles are events, and diamonds are gateways. Event borders and internal markers carry meaning; for example, a start event has a thin border and an end event a thick one. An exclusive gateway chooses one route; a parallel gateway, marked with a plus, splits or synchronizes parallel routes. A diamond is therefore not always a yes/no question.

Pools represent participants in a collaboration; lanes organize work within a pool. Sequence flows show execution order within a process, while message flows show communication between participants in different pools. They are not interchangeable arrows. Camunda’s BPMN primer explains the roles of tasks, flows, gateways and events.

Choose one notation and follow its rules. In particular, do not borrow UML’s start circle, a flowchart’s database symbol and BPMN’s message arrows while assuming that the result retains all three standards’ meanings.

How to draw and use a process map

1. Define the question and boundaries

Write what decision the map should support, which scenario it covers, what starts the flow and which outcomes end it. “Everything in onboarding” is broad; “company-details form opened until details are saved or the customer cannot continue” creates a manageable boundary.

2. Gather the people and evidence

Include the people who perform or support the work and check relevant observations, records or system behavior. Map the current state separately from a proposed future state. Mark assumed steps, missing information and disagreements instead of drawing them as established facts.

3. List actions at a consistent level of detail

Write one action per note using a verb and object. Start with the main sequence, then expand the area relevant to the question. Avoid mixing a whole department’s workflow with individual clicks in the same chain; use a separate detailed map when necessary.

4. Connect decisions, exceptions and handoffs

Choose a notation and a consistent reading direction. Add clear branch conditions, recovery loops and important failure outcomes. Use lanes when they clarify responsibility. An arrow between two boxes must show an intended next step; proximity alone does not explain the connection.

5. Walk through real cases

Ask someone who does the work to follow a recent case through the map. Check the ordinary path and relevant exceptions against evidence. Where does work wait, repeat, change owner or fail? Camunda’s readability guidance emphasizes meaningful labels and explicit paths; visual neatness cannot replace a correct account.

6. Decide what to investigate or change

Mark the problem area and assign an owner to the next observation, comparison or improvement. If proposing a new flow, keep it distinct from the current one and decide how to check its outcome. Record the map’s scope, date and owner so later changes do not leave the team relying on an obsolete picture.

For a facilitated examination of a product task, use Flow Analysis. For the people, systems and backstage work supporting an experience, use Service Blueprint.

How a process map helps root cause analysis

A process map makes the flow visible enough to compare it with what happened:

• Locate the break. Mark the step where a symptom appears, such as an error, a drop-off or a delay, and the steps just before it.
• See handoffs and decisions. Problems often appear where work passes between people, teams or systems, or where the flow branches.
• Compare intended and actual. A map of the process as designed, overlaid with observed paths, shows where practice differs from the plan.
• Constrain hypotheses. A possible cause that sits in a part of the flow the failing cases never reach is unlikely to explain them.

A map shows where to look. It does not explain why the problem occurs, and a map of the intended process can hide the workarounds and exceptions where many failures start.

Which mapping exercise should you use?

Different maps answer different questions. Choose the one that fits what you need to see:

You want to map	Use	What it shows
The front and backstage of a service	Service Blueprint	The customer’s steps alongside the people, processes and systems that support each one
How users move through a product to complete a task	Flow Analysis	Task and user flows, and where actual paths diverge from the intended ones
Where customers drop out of a sequence of stages	Funnel Mapping	Conversion between stages, and the bottlenecks between them
A typical customer’s experience over time	Journey Mapping	Actions, thoughts and feelings across the journey; see also customer journey map
One specific failure, as it actually happened	Incident Timeline	The sequence of events before, during and after the failure, with evidence and gaps marked

The first four describe a typical or intended flow. The incident timeline reconstructs one occasion. In an investigation they often work together: a blueprint or flow map locates the step and the systems involved, and a timeline establishes what changed there and when.

A worked example

The following flow and observations are illustrative. They are not results from an actual customer study or incident.

The subscription service from the root cause analysis guide maps its setup flow as designed: sign up, enter company details (typed or autofilled), press Continue, validate, save, create a first invoice. On this map, both entry paths reach Save.

The team then overlays what it observed in support tickets and usability sessions. The reports cluster in one place: customers press Continue on company details and get a generic error, and the complaints mention autofill. To see that step properly, the team splits the “enter company details” box into what happens on screen and what is submitted. The map now shows a gap the intended version hid: between “the field shows a value” and “the value is submitted”.

The map tells the team where to investigate, not what is wrong there. The root cause analysis guide shows how it then reproduces the failure and establishes the mechanism.

Limitations

A map of the designed process is not evidence about the actual one. Check it against observations, logs or the people who do the work, and label which version you drew.

Locating a step is not explaining it. The step where a symptom appears may not be where the cause is. A problem earlier in the flow, or outside it, can surface later.

Detail is a trade-off. Too little detail can hide the step that matters, as in the example. Too much makes the map hard to read and maintain. Add detail around the problem area rather than everywhere.

A neat main path can hide the actual problem. Include relevant waits, exceptions, rework and error outcomes. A diagram showing only successful completion can omit the very behavior the team needs to understand.

A typical flow does not show one incident. For what happened during a specific failure, reconstruct it with an incident timeline instead.