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 decision flowchart maps a sequence of choices: each decision is a question, each exit is labelled with an answer, and the answers together cover every case exactly once.
The short version
- Every diamond holds a question, phrased so the reader can answer it.
- Exits are exhaustive and mutually exclusive: every case matches exactly one.
- The criteria belong on the chart, not in the author's head.
- Prefer two clear decisions in sequence over one with five exits.
- Order the questions so the cheapest, most eliminating one comes first.
What makes a decision chart usable under pressure
A decision flowchart is read by someone who has to choose, usually quickly, and often without the context the author had. That is a harder audience than a process map gets. It means the questions have to be answerable from information the reader actually holds, the exits have to cover every case, and the criteria cannot live in the author's head: "is this critical?" is only a decision if the chart says what critical means.
The technical requirement is that each decision's exits are exhaustive and mutually exclusive: every case matches exactly one route. Exhaustive fails when the reader's situation is not listed, and they invent a path. Exclusive fails when two routes both apply, and two readers make different calls from the same chart, which looks like inconsistency in the team and is actually a defect in the diagram.
The example below is a bug triage flow, which is decisions almost end to end: can it be reproduced, has it been reported before, how severe is it, did the fix pass review, did it pass verification. Six decisions, four of which can send the item backwards.
Six decisions, one defect
Bug triage from report to closure. Almost every step is a choice, and most of them can send the item backwards.
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.
Mistakes to avoid
Vague criteria
"Serious", "urgent", "significant": each reader supplies their own threshold, and the chart delivers the appearance of standardisation without any of it.
Overlapping exits
If an item can legitimately take two routes, two people will route it differently and both will be right. Make the split exclusive.
A decision with one exit
If only one route is drawn, it is not a decision. Either draw the other outcome or make it a process step.
Nesting five decisions deep
Long decision chains are hard to trace and harder to change. Where the tree is genuinely wide, a decision table alongside the chart is usually clearer than more diamonds.
Create your own decision flowchart
Open the bug triage example as your own chart, then replace the questions with the decisions your team actually makes.
Related guides
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.