How to create a decision flowchart
How to create a decision flowchart: write each decision as a question, make the exits exhaustive and exclusive, state the criteria, and give every outcome an ending. With a live bug-triage example.
A worked example, stage by stage
The cheapest question first
Can it be reproduced? Nothing downstream is worth doing until that is answered, so it comes first. Ordering decisions by how much work they eliminate is the single biggest improvement you can make to a triage chart.
Give the dead ends real endings
No reply from the reporter closes the item as cannot-reproduce; a duplicate is linked and closed. Both are legitimate outcomes with their own terminators — a triage chart that only ends in "fixed" does not describe triage.
Route by severity, and say what severity means
Critical raises a production incident and skips the backlog; standard goes to the owning team. Write the definition of critical next to the decision, or two people will triage the same defect differently and both will be following the chart.
Decisions that loop backwards
Code review and verification each send failures back to development, and a failed verification reopens rather than closing. Loops are what make a decision chart honest about rework.
How it works
List the questions before the answers
Write down every choice the process contains, as questions. Then sort them by how much work each one eliminates: the question that closes the most cases with the least effort goes first. Triage charts that ask the expensive question first waste the effort they were built to save.
Make each question answerable
Check that the reader can answer it from what they have in front of them. "Is this a duplicate?" works if there is a searchable tracker; "is this a known issue?" does not, unless the chart says where known issues are listed.
Write the criteria onto the decision
Put the threshold in the step's comment: what makes a defect critical, what counts as sufficient evidence, what value triggers the extra approval. A decision without stated criteria produces consistent-looking diagrams and inconsistent decisions.
Check the exits cover every case, once
For each decision, ask whether there is a situation that matches none of the exits, and whether there is one that matches two. Both are defects. Three-way splits are fine — standard, normal, emergency — as long as every case lands in exactly one.
Draw the loops honestly
Failed review, failed verification, reopened after closure: each of these goes back into the flow at a specific step. Pretending work is linear is how estimates end up describing a process nobody has ever experienced.
Test it against real cases
Take ten items that went through the process last month and walk each one through the chart. The ones that do not fit are telling you about a missing exit or a criterion that only exists in someone's judgement.
Frequently asked questions
What is a decision flowchart?
A flowchart whose structure is dominated by decision points rather than sequential activity: each diamond asks a question and each labelled exit routes to a different course of action. Triage, eligibility checks, escalation rules and approval routing are all decision flowcharts. The design constraint that distinguishes them is that the exits from each decision must cover every case exactly once, so any reader following the chart reaches the same outcome.
Can a decision have more than two outcomes?
Yes, as long as the outcomes are exhaustive and mutually exclusive. A change request splitting into standard, normal and emergency is a clean three-way decision. What causes trouble is a decision with five or six exits, which usually turns out to be two decisions wearing one diamond — splitting it in two makes both easier to answer and much easier to change later.
Where should decision criteria be written?
On the decision itself, not in an appendix. In QueryChart each step carries a comment field, which is where the threshold, the definition or the reference to the policy belongs. Criteria kept in a separate document are consulted once, remembered approximately, and applied inconsistently — which defeats the purpose of documenting the decision at all.
How do I show a decision that loops back?
Point the exit at the row number of the step it returns to. A failed code review going back to development, or a failed verification reopening the defect, are both single connections back into the middle of the chart. Loops are normal and drawing them is what makes a decision chart honest about how much rework the process really contains.