Decision Tree Flowchart
The code
flowchart TD
A[New request arrives] --> B{Is it a bug?}
B -- No --> C{Is it a question?}
C -- Yes --> D[Route to docs team]
C -- No --> E[Log as product feedback]
B -- Yes --> F{Blocks a release?}
F -- Yes --> G[Page the on-call engineer]
F -- No --> H[Triage for next sprint]
G --> I[Open incident channel]
H --> J[Add to backlog]
D --> K((Resolved))
E --> K
I --> K
J --> K
How this template works
This template is a routing machine: a request enters at the top, answers a series of yes-or-no questions, and lands in exactly one destination. It is the shape to reach for whenever a team makes the same classification decision dozens of times a day — support intake, bug triage, lead qualification, or refund policy. The value is not in any single answer but in the fact that everyone follows the same questions in the same order.
The structure is a chain of diamonds. The first line, flowchart TD, sets a top-down direction, which keeps the question hierarchy readable. Each diamond such as B{Is it a bug?} is a question, and each labeled edge leaving it is one possible answer: B -- No --> C continues down the chain while B -- Yes --> F jumps to a deeper question. Notice that the diagram mixes two patterns. Nodes B and C form a linear chain of questions, while node F splits into an urgent path that pages a human and a calm path that ends in a backlog entry. Every branch, no matter how far it wanders, eventually flows into the single terminator K((Resolved)), drawn with double parentheses to mark it as an endpoint rather than a step.
The gotcha in this template is dangling branches. When people add a question, they often connect the new diamond but forget to connect its answers to anything, leaving paths that trail off into nothing. Before you share the diagram, trace every edge from the start node and confirm each one reaches a terminator. The second trap is punctuation in labels: a question like C{Refund over 50, or escalate?} contains a comma, which confuses the parser — wrap it in quotes as C{"Refund over 50, or escalate?"} and it renders correctly.
Adapting the tree is mostly a matter of rewriting the questions. Keep each one answerable with a strict yes or no; a question with three possible answers needs two diamonds. If a branch turns out to be unreachable in practice, delete it rather than leaving dead paths in the diagram — dead branches are how runbooks drift from reality.
Related templates: the customer support triage flowchart applies the same questioning pattern to tickets, the incident response flowchart covers the urgent path in more depth, and the approval workflow flowchart shows a decision chain with a money threshold. The flowchart diagram guide documents every node and edge shape.
Variations to try
- Add a third question level under node F to separate security bugs from ordinary defects.
- Replace the paging step with a subgraph named Escalation so the urgent path is visually grouped.
- Duplicate the file and rename the labels to build a refund policy tree for a finance team.
