The difference between a process map and a workflow

"Process map" and "workflow" are used interchangeably in most organisations, and the confusion has a cost. One person is asked for a process map and produces forty boxes covering every keystroke. Another is asked for the workflow and delivers six stages with a team name under each. Both are reasonable readings of the request, and neither is what the person asking had in mind.

The terms describe different levels of the same thing. Being precise about which one you need saves a round of rework, and it makes both diagrams better, because each can leave out what belongs in the other.

Two definitions worth agreeing on

A process map shows the stages a piece of work moves through from trigger to outcome, who owns each stage, and what passes between them. It answers the question: what happens, in what order, and who is responsible? It works at the level of stages rather than tasks. "Assess eligibility" is a stage. "Open the order record and check the purchase date" is a task inside it.

A workflow is the detailed sequence of tasks and decisions inside one of those stages, or inside a small process end to end, with the rules that determine which path a given case takes. It answers the question: exactly what do I do next, and how do I know? Workflows contain the conditions, thresholds and exception paths that a process map deliberately omits.

Neither definition is an official standard. Different methods use different vocabularies, and some organisations call everything a workflow. What matters is that the people drawing and reading the diagram agree which level they are working at before anyone starts.

Levels of detail

A common way to think about process documentation is as a set of nested levels, each zooming into one box of the level above. The labels vary between organisations, but the shape is consistent.

The process map and the workflow sit next to each other in the middle. The practical test for which one you are drawing is the step names. If most of them would need a paragraph of explanation before someone new could carry them out, you are at process level. If a new team member could follow each one with the diagram alone, you are at workflow level.

Mixing levels on one diagram is the most common reason process documentation becomes unreadable. A box called "Finance review" next to a box called "Click Submit" tells the reader that nobody decided who the diagram was for.

Who each one is for

A process map is for people who need to understand the shape of the work without doing it: managers deciding where to invest, a new head of department learning how things run, an auditor checking that responsibilities are clear, or two teams arguing about where one's job ends and the other's begins. It should fit on one page and be readable in a couple of minutes.

A workflow is for the people who carry out the work, and for anyone automating it. A support agent needs to know that refunds outside thirty days go to a manager. A developer configuring a ticketing system needs to know every state a ticket can be in and every condition that moves it. These readers need precision, and they will read the whole diagram carefully because they have to.

The audiences pull in opposite directions. Senior readers want less detail and will stop reading if they get more. Operational readers want more detail and will stop trusting the diagram if a case they handle every day is missing. Trying to serve both on one page usually fails both.

Worked example: a refund process drawn both ways

Take an online retailer's refund process. A customer asks for a refund; eventually the money goes back and the customer is told. Several teams are involved, there is a policy with a time limit, and there is a manager-level exception route. It is small enough to draw both ways and large enough for the difference to show.

As a process map

At process level the refund is five stages, each with one owner:

1. Request received (Customer service)
2. Eligibility assessed (Customer service, with a manager for exceptions)
3. Returned item inspected (Warehouse)
4. Refund issued (Finance)
5. Customer notified (Customer service)

That is the whole diagram. There is no thirty-day rule on it and no decision diamond about condition. What it shows clearly is that the work leaves customer service twice and comes back, which means two handoffs and two places for a refund to stall. A head of operations looking at this can ask the useful question immediately: who notices if the warehouse never inspects the item?

The same pattern, applied to a different process, looks like this. Each stage carries the name of the team that owns it, and the diagram makes no attempt to show how any stage is done.

As a workflow

Zoom into the eligibility stage and the refund looks different. Now the rules matter. Is the request within thirty days? If not, will a manager approve an exception? Has the item been checked? Each condition becomes a decision with labelled branches, and the rejection path is drawn explicitly because a customer service agent needs to know what to say when the answer is no.

This version has no team names on it, because within the stage it describes, the owner is obvious. It has instead the thirty-day threshold, the exception route and the decline path. If the policy changes to forty-five days, this diagram changes and the process map does not. That is a good sign that the two are working at different levels.

What each version is good for

Give the process map to someone deciding whether refunds should move to the finance team entirely. Give the workflow to a new agent on their first day, or to the person setting up the refund screens in the order system. Neither would be well served by the other's diagram.

Side by side

How to decide which one you need

Most requests for "a process diagram" can be sorted with a few questions before anyone opens a canvas.

• If the problem is that teams disagree about who does what, draw a process map in lanes.
• If the problem is that cases are handled inconsistently, draw the workflow for the stage where the inconsistency happens.
• If you are about to automate something, you need the workflow. Software cannot act on "assess eligibility".
• If the reader will spend under five minutes on it, draw the process map.
• If someone will follow it while doing the work, draw the workflow.
• If you cannot tell, draw the process map first. It will show you which workflow is worth the effort.

Mistakes that blur the line

Most bad process documentation is not wrong so much as confused about its level. These are the patterns worth checking for before a diagram goes out.

• A process map with decision diamonds for policy rules. If a box asks "Within 30 days?", the diagram has dropped into workflow detail. Move the rule into the workflow for that stage and keep only the outcome on the map.
• A workflow that changes owner every second step. If the lines cross between teams constantly, the diagram is really a process map drawn too finely, or it needs lanes so the handoffs can be read.
• Stage names that are really departments. "Finance" is not a stage; "Refund issued" is. A process map built from department names shows the organisation chart, not the flow of work.
• Workflows with no ending for the unhappy path. Every decision branch has to land somewhere: an end state, a loop, or a handoff to another workflow.
• One diagram trying to serve as both. The usual symptom is a page that is too dense for managers and still missing the exception a front-line team handles daily.

A quick check is to read the step names aloud in order. At process level they should sound like a summary someone could give in a hallway. At workflow level they should sound like instructions. If the list switches register halfway through, the diagram has switched level too.

Keeping the two in step

Once you have both, they need to agree. The simplest discipline is naming: each stage on the process map should have the same name as the workflow that expands it. If the process map says "Eligibility assessed" and the workflow diagram is titled "Refund approval checks", someone will eventually maintain one and forget the other.

The boundaries need to match too. The first step of a workflow should be the event that the process map shows entering that stage, and the workflow's possible endings should correspond to the arrows leaving it. If the workflow has a "Declined" ending, the process map needs somewhere for declined refunds to go, even if it is just an arrow to "Customer notified".

Finally, date both. A workflow is far more likely to change than the map above it, and an undated diagram gives no clue whether it reflects last year's thresholds or this year's.

Drawing both in DiagramDock

DiagramDock has a process map type, a flowchart type and a swimlane type, so the two levels can be drawn with the palette suited to each. The process map templates, such as client onboarding and support escalation, are drawn at stage level; the flowchart templates, such as the refund process, are drawn at workflow level, which makes them a reasonable reference for where the line sits.

Frames can group areas of a larger diagram and become slides in presentation mode, which is useful when walking a group from the process map into one of its stages. Diagrams are saved in your browser rather than on a server, and can be exported as SVG or PDF for documentation.