Process Flow Diagram: How to Visualize Any Workflow

A process flow diagram shows a whole workflow from trigger to outcome: the stages work passes through, the decisions that redirect it, the handoffs between them, and the outputs each stage produces. You build one by fixing the boundaries first — what starts it, what ends it — then listing the stages in order, marking the points where the flow can branch or loop back, and naming what each stage hands to the next. One warning before you start: the term means two different things, and the diagram you need depends on which one you are being asked for.

Live interactive diagramUse the player controls to follow the steps

How a cheque clearsPlaying silently in this guideWatch with narrationOpen in editor

What this diagram shows

1. The flow starts when a payer writes a cheque.
2. The payee deposits it at their bank, which captures a digital image — the step known as truncation.
3. The image is sent to the clearing house and presented to the payer's bank.
4. A decision asks whether funds are available and the cheque is valid.
5. If yes, the banks settle the amount and funds are made available to the payee.
6. If no, the cheque is returned unpaid and a document records the bounce: a fee is charged and the payee notified.

First, which process flow diagram do you mean?

In business, operations and software, a "process flow diagram" is a workflow picture: stages, decisions, handoffs, outputs. That is the one this guide is about, and the one most people searching the phrase want.

In chemical and process engineering, a PFD is a specific, formal deliverable. It shows major equipment, process streams and the mass and energy balance for a plant, and it is standardised in ISO 10628-1:2014, which specifies the classification, content and drafting rules for those diagrams, with its symbol library in ISO 10628-2:2012. A PFD in that world sits between a block flow diagram and a P&ID, and it carries stream temperatures, pressures and flow rates. If someone has asked you for a PFD of a refinery unit, you need that standard and its symbol library — not this article.

Ask which one is wanted before you draw. The two diagrams share a name and nothing else.

When a process flow diagram is the right level

The distinguishing feature is altitude. A process flow diagram works at the level of stages — bodies of work with a name, an owner and an output — rather than individual actions. That makes it the right tool when:

• The workflow crosses functions. An order that touches sales, credit, fulfilment and finance is a flow, not a procedure.
• You are looking for where work stalls. Delay usually lives between stages, not inside them, and a flow diagram is the artefact that makes the joins visible.
• You need one shared picture for people who each know one part. The value is that nobody in the room can see the whole thing without it.

If instead you are documenting the branching logic of a single procedure, you want a flowchart — see how to create a flowchart, and flowchart vs process map if you are still deciding.

How to build one, step by step

1. Fix both boundaries. Write the trigger and the outcome as one sentence each: "Starts when a cheque is deposited; ends when funds are available or the cheque is returned." Everything else follows from this, and without it the diagram expands until someone gives up.
2. List the stages, not the clicks. Five to nine is the useful range. If you have thirty, you are listing actions — group them, and let each group become a stage.
3. Name each stage as work, not as a department. "Credit check", not "Finance". Departments go in lanes later, if you need them at all; a stage named after a team stops describing what happens.
4. Put them in order and draw the main path. One direction, left to right or top to bottom, straight through. This is the version of the process that happens most of the time.
5. Add the decisions that redirect the flow. Only the ones that change which stage comes next. A decision inside a stage is that stage's business.
6. Draw the return paths honestly. Rework loops, rejections, escalations. These are usually the reason the diagram was commissioned, and the commonest thing left off it.
7. Name the handoff on every arrow that crosses a stage boundary. What is actually passed — an approved quote, a claim file, a signed order? An unnamed handoff is where processes fail in real life.
8. Mark the outputs. Documents, records and artefacts a stage produces get their own shape, so a reader can see what the process yields as well as what it does.

A worked example: how a cheque clears

The diagram at the top of this page is a complete workflow in ten shapes, and it is a good example because the interesting part is not the happy path.

It starts when a payer writes a cheque and the payee deposits it. The bank captures a digital image — the step the industry calls truncation, and worth naming precisely because it is where the paper stops travelling and the data starts. The image goes to the clearing house and is presented to the payer's bank.

Then the only decision: are funds available and is the cheque valid? Yes, and the banks settle and the payee gets the money. No, and the flow takes its return path — the cheque is returned unpaid, and a document records the bounce, the fee and the notification.

That return path is the whole reason to draw this. Everyone can describe the happy path from memory. Almost nobody can tell you, without looking, what happens on the day it bounces, who is told, and who pays the fee.

Workflows you can open and edit

Each of these is an editable diagram. Open one, add a stage, and watch the connectors re-route.

Building one in Diagramium

Open the process map editor, which is the tool shaped for this — stages, gateways and handoffs rather than the finer-grained flowchart vocabulary.

1. Drop your stages in order along one axis, before worrying about anything else.
2. Connect them by dragging from a port on a stage's edge. Connectors route around shapes rather than through them.
3. Label the crossing arrows with what is handed over — select a connector and set its label in the inspector.
4. Add the return paths last, so they read as exceptions rather than competing with the main line.
5. Press Present to walk the flow one stage at a time. For a process nobody has seen end to end, revealing it in sequence lands considerably better than putting the finished picture on screen and talking over it.

Exports are PNG, SVG and PDF without an account; animated SVG, GIF and video need a free account. You can also embed the diagram in a runbook or wiki so it stays current instead of becoming a stale screenshot.

Best practices

• One altitude throughout. If one shape is "Underwriting" and the next is "Tick the box on form 4B", the diagram has lost its level and readers stop trusting it.
• Between five and nine stages. Fewer says nothing; more should be split into a second diagram at a lower level.
• Name handoffs as nouns. "Approved quote" beats "sends it on".
• Draw the current process before the improved one. Two diagrams, clearly labelled. A single diagram that mixes them is a proposal disguised as documentation.
• Get it wrong in front of the people who do the work. A draft with three mistakes in it produces better corrections in ten minutes than a blank page produces in an hour.
• Date it. A process diagram with no date is assumed current forever, which is how wrong ones survive.

Common mistakes

• Leaving out the unhappy paths. The rejections and rework loops are where the cost is. A diagram of only the happy path documents the version of the process nobody needs help with.
• Stages named after teams. This bakes the current org chart into a document about work, and it goes stale the next reorganisation.
• Unnamed handoffs. An arrow that just says "then" hides the artefact, and the artefact is what gets lost.
• Mixing the two meanings. Using engineering PFD symbols on a business workflow, or vice versa, confuses both audiences.
• Documenting the process you were told about. Walk it with someone who does it. The gap between the two is usually the finding.

Related diagram types

• To show who owns each stage and where work crosses teams, put the same flow in lanes: how to create a swimlane diagram for business processes.
• To document the branching logic inside one stage, drop a level to a flowchart, and check what each symbol means.
• To follow the data rather than the work, use a data flow diagram.

In short

A process flow diagram is a workflow at the level of stages: boundaries fixed, main path straight, return paths drawn honestly, and every crossing arrow naming what it carries. Keep it to five to nine stages, date it, and validate it with the people who actually run the process. And if the person asking works in process engineering, check which kind of PFD they meant before you start.

Questions people actually ask

What is a process flow diagram?

A diagram showing a workflow end to end — the stages work passes through, the decisions that redirect it, the handoffs between stages, and the outputs produced. In chemical engineering the same term means a formal plant drawing standardised by ISO 10628, which is a different artefact entirely.

What is the difference between a process flow diagram and a flowchart?

Altitude and scope. A flowchart documents the branching logic of one procedure; a process flow diagram covers a whole workflow at the level of stages, usually across several teams. There is a full comparison in flowchart vs process map.

How many steps should a process flow diagram have?

Five to nine stages. Below five it rarely tells anyone anything they did not know; above nine, split it into a high-level diagram plus one lower-level diagram per stage that needs it.

What symbols does a process flow diagram use?

For business workflows, the standard flowchart vocabulary: rounded rectangles for start and end, rectangles for stages, diamonds for decisions, document shapes for outputs — see flowchart symbols and meanings. Engineering PFDs use the entirely separate ISO 10628-2 symbol library for equipment and streams.

Should a process flow diagram show who does the work?

Only if ownership is the question. Adding lanes turns it into a swimlane diagram, which is the right move when handoffs are the problem and the wrong one when they are not — lanes cost horizontal space and add nothing if a single team owns the flow.

Can I present a process flow diagram one stage at a time?

Yes. Present mode reveals the diagram step by step with a note per stage, which suits a process most of the room has only ever seen one part of.