How to create a process flowchart
How to create a process flowchart: fix the trigger and the end state, write one action per box, turn every 'if' into a labelled decision, and close every branch. With a worked example you can step through.
A process flowchart shows the order work actually happens in: one trigger, one action per box, a labelled decision wherever the path forks, and an explicit end state on every branch.
The short version
- Fix the trigger and the finish line first; everything else is the middle.
- One action per box, phrased verb-first: "Capture invoice in AP system", not "Invoicing".
- Every decision is a question, and every exit off it carries a label.
- Every branch rejoins the flow or ends in its own terminator, with no lines stopping in mid-air.
- The exception path is the part that earns the diagram its keep.
What makes a flowchart a flowchart
Most first attempts at a process flowchart are not flowcharts. They are a row of rectangles joined by arrows, describing the version of the process where nothing goes wrong. That drawing is a checklist with extra steps, and it is why so many process diagrams get made once, printed, and never looked at again. Everyone already knows the happy path. The value is in what the chart says about the other paths.
A working flowchart has a small, strict grammar. One start. One action per box, phrased verb-first so it is clear who does what. A decision drawn as a question with every exit labelled, so a reader can tell which way they are going. And every branch either rejoins the main flow or ends in its own terminator, because a line that stops in mid-air means nobody knows what happens next, which is exactly the situation the chart was meant to fix.
The example below is a real invoice approval process, built up in five stages. Watch what happens at each one: the chart gets useful precisely when the exceptions arrive: the duplicate invoice, the price that does not match the purchase order, the query that goes back to the supplier and re-enters the flow further up. Those three branches are the whole reason the diagram is worth more than the checklist.
Watch a process flowchart get built
Five stages of a real invoice approval flow. Step through them: each one adds the next piece of flowchart grammar.
One trigger, one first step
Every flowchart starts with exactly one Start shape, and it names an event rather than an activity: an invoice arriving, not "invoice processing". If your chart has two starts, you are drawing two processes.
Ask the first question
The diamond is a question ("Duplicate invoice?"), and both exits are labelled. Notice the Yes branch does not trail off: it ends in its own terminator, because blocking a duplicate is a legitimate end to this process, not a failure to finish the drawing.
Split the paths that genuinely differ
A PO-backed invoice gets a three-way match against the purchase order and the goods receipt; a non-PO invoice gets coded to a cost centre instead. Two branches, because the work is genuinely different, not because someone wanted the chart to look thorough.
Send the exception back into the flow
A price mismatch raises a query with the supplier, and once it is resolved the flow re-enters at the PO check rather than starting over. Loops back into the middle of a process are normal; what is not normal is an exception branch that quietly disappears.
End on a state, not an activity
Approval routes by value, a countersignature is required above the threshold, and the chart finishes at "Supplier paid and remittance sent": a state you can verify. "Process payment" would be an activity, and an activity is never a finish line.
How it works
Write down the trigger and the finish line first
Before any boxes: what event starts this process, and what state means it is done? Those two sentences set the scope, and most arguments about a flowchart turn out to be arguments about the boundaries rather than the steps. Write the finish line as a state ("supplier paid"), not as an activity.
List the steps as rows, not as a drawing
In QueryChart, open a new chart and type the steps into the Box text column one per row. Resist laying anything out. A list is faster to argue about than a diagram, and the layout is generated for you: the routing is done by the app, so nothing you do by hand here survives anyway.
Connect the rows by number
The Line to column takes the row number of the next step, so row 2 pointing at 3 draws the arrow. Type multiple numbers separated by commas where a step leads to more than one place. This is the whole of connecting a flowchart in QueryChart, and it is why the chart can be edited by someone who has never used a diagramming tool.
Turn every "if" in your notes into a decision
Anywhere your notes say "if", "unless" or "depending on", set that row's Shape to Decision and rewrite the label as a question. Then put the answers in the Line text column ("Yes", "No", "Over £10k"), so each exit says which case it is. An unlabelled fork is the single most common reason a flowchart cannot be followed.
Draw the exception path
Take each decision's unhappy branch and follow it to a real conclusion: does it loop back to an earlier step, hand off to someone else, or terminate? Give it a terminator shape when it ends. This is the part people skip, and it is the part readers actually need: nobody consults a process map to find out what happens when everything works.
Walk it with someone who does the work
Read the chart aloud to whoever runs the process and ask where it is wrong. Expect to find one step that is really three, and one branch nobody had ever written down. Fix it in the rows, share the chart, and put an approval on it so the version people are looking at is the agreed one rather than a screenshot in someone's slide deck.
Mistakes to avoid
Decisions phrased as statements
"Manager approval" is a step; "Manager approves?" is a decision. If a diamond does not read as a question, the two lines coming out of it cannot be labelled sensibly, and the reader has to guess which one applies to them.
Branches that stop in mid-air
Every line has to arrive somewhere: another step, or a terminator. A branch that simply ends is the chart admitting nobody knows what happens in that case, which is worth knowing, but should be fixed rather than drawn.
One box doing three things
"Review and approve and file" is three boxes with two possible failure points hidden between them. If a step's label needs an "and", it is usually more than one step, and the handoff you cannot see is where the delay lives.
Charting the process you wish you had
Map the as-is process first, exceptions and workarounds included, even when it is embarrassing. A to-be chart drawn before anyone has agreed what happens today is a proposal, and it should be labelled as one.
Create your own process flowchart
Start from the invoice approval example above, or clear it and type your own steps into the rows.
Related guides
Frequently asked questions
What shapes do I need for a process flowchart?
Four carry almost everything: a terminator for the start and each end state, a rectangle for an action, a diamond for a decision, and a document shape for a step that produces a record: a signed form, a report, a logged entry. QueryChart also offers Reject and Success terminators, which is useful because a chart usually has more than one way to finish and colouring them differently makes the unhappy endings visible at a glance.
How detailed should a process flowchart be?
Detailed enough that someone who does not do the job could follow it, and no more. A practical test: if a step could be handed to a different team without further explanation, it is one box. If explaining it takes a paragraph, it is probably a sub-process that deserves its own chart, linked from this one. Fifteen to twenty-five boxes is the range where most operational processes stay readable on one screen.
What is the difference between a process flowchart and a process map?
A flowchart shows sequence and logic: what happens, in what order, with what decisions. A process map adds context around that sequence: who owns each step, which system it happens in, what goes in and what comes out. In practice the distinction is mostly about lanes: the moment you split the flow by owner you have a process map, and that is usually the version worth having for anything that crosses a team boundary.
Do decisions always have to be yes or no?
No, but they should be exhaustive and mutually exclusive. A three-way split on change type (standard, normal, emergency) is fine as long as every request lands in exactly one of them. What breaks a chart is a decision whose labelled exits do not cover every case, because the reader whose situation is missing has nowhere to go and will invent a path of their own.