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 worked example, stage by stage
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.
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.