What is a decision tree
A decision tree is a directed acyclic graph where each internal node asks a question, each branch encodes a possible answer, and each leaf node delivers a final outcome. The structure makes multi-step conditional logic auditable in a way that nested if-else code or prose policy documents cannot — a reader can trace any path from root to leaf in seconds.
Decision trees appear in two distinct contexts. In business and operations, they are manually authored policy diagrams: loan approval rules, customer support routing scripts, clinical triage pathways. In machine learning, they are statistical models inferred from training data — the splits are chosen algorithmically to maximise predictive accuracy. The visual structure is identical; the authoring method is not.
A decision tree is also closely related to a flowchart. Both use decision diamonds and directional arrows. The key difference: a decision tree has no process steps between decisions and no loops — every node is either a decision or a terminal outcome. Use a flowchart for sequential processes; use a decision tree for pure classification or routing logic.
Node types reference
| Symbol | Name | Description | When to use |
|---|---|---|---|
| ◇ | Decision node | Diamond shape. Represents a question or condition with two or more outgoing branches. | Every branch point where the path depends on a condition or attribute value. |
| ▭ | Process rectangle | Rectangle. An action or step performed before or after a decision. | Steps that execute unconditionally — logging, sending a notification, updating a record. |
| ◯ | Terminal node | Oval or rounded rectangle. The final outcome, classification, or action at the end of a path. | Every leaf: an approval, rejection, classification label, or escalation endpoint. |
| → | Branch arrow | Directed connector. Represents the flow from a decision node to the next node. | All transitions. Label each arrow with the condition it represents (Yes/No, ≥ 700, etc.). |
| [ ] | Branch label | Text annotation on a connector. Names the condition or value that activates this branch. | Every outgoing edge of a decision node. Omitting branch labels is the most common decision tree error. |
BPMN gateway types for decision trees
When a decision tree is embedded in a BPMN 2.0 process, gateways replace diamond nodes. The gateway type determines how many outgoing paths are activated. For decision trees, the exclusive (XOR) gateway is almost always correct.
| Gateway | Symbol | Meaning | Example |
|---|---|---|---|
| Exclusive (XOR) | ✕ | Exactly one outgoing path is taken — the first condition that evaluates to true. | Credit score ≥ 700 → Approve; else → Manual review. |
| Inclusive (OR) | ○ | One or more outgoing paths are taken simultaneously based on independent conditions. | Send email AND/OR SMS notification based on user preferences. |
| Parallel (AND) | + | All outgoing paths are activated unconditionally in parallel. | Trigger background check AND identity verification simultaneously. |
| Event-based | ⬡ | Routes based on which event occurs first — a message, timer, or signal. | Customer replies within 24 h → Continue; 24 h timer fires → Escalate. |
Business use cases
| Domain | Decision being made | Branching logic |
|---|---|---|
| Loan approval | Approve, refer to underwriter, or decline | Credit score → debt-to-income ratio → collateral value → employment status → decision leaf. |
| Customer support routing | Self-serve, tier-1 agent, or tier-2 specialist | Issue category → account tier → prior contact in 30 days → sentiment score → routing leaf. |
| Clinical diagnostic pathway | Treatment protocol or further testing | Symptom cluster → lab results → risk factors → age band → recommended protocol leaf. |
| Dynamic pricing | Apply discount tier or standard rate | Cart value → customer segment → inventory level → days to event → price leaf. |
How to generate a decision tree with flow-chart.io
- Create a free account — 40 AI credits/month, no credit card required. Each standard decision tree costs approximately 4 credits.
- Describe your decision logic in plain language — for example: "Loan approval: if credit score is below 580, decline; if 580–699, route to underwriter review; if 700 or above, check debt-to-income ratio — if DTI is above 43%, decline; otherwise, approve." The AI maps your description to correctly typed nodes with labelled branches.
- Edit and refine — click any decision diamond to rename its condition, add or remove branches, or promote a leaf into a new sub-tree. The layout reflows automatically.
- Export — SVG for embedding in Confluence or Notion, PNG for slides and documents, PDF for print, JSON to store in version control alongside the policy it documents.
Decision tree best practices
- Keep each decision binary (Yes/No or True/False) — ternary splits double the cognitive load.
- Label every branch with its specific condition value, not just "Yes" and "No".
- Name every leaf node with a concrete outcome: "Approve", "Decline", "Escalate to Tier 2".
- Limit tree depth to five levels for any single diagram; link deeper sub-trees as separate diagrams.
- Verify completeness: every possible combination of conditions must reach exactly one leaf.
- For ML trees, always report the training accuracy and pruning criterion alongside the diagram.
- Order siblings with the most common case (happy path) on the left or top branch.
Export formats
SVG (vector, scalable)
PNG 2× and 4×
PDF (print-ready)
JSON (re-importable scene graph)
Mermaid (.mmd)
All exports are derived from the scene graph, not screen captures. SVG scales without pixelation at any zoom level. JSON lets you re-import the diagram into flow-chart.io for further editing or store it in version control alongside the policy it documents.
Frequently asked questions
- What is a decision tree?
- A decision tree is a diagram that models a sequence of decisions and their possible consequences as a branching tree structure. Each internal node represents a decision or test on a variable; each branch represents the outcome of that test; each leaf node represents a final outcome or classification. Decision trees are used in business analysis (routing customer requests, approving loans), machine learning (classification and regression models), and clinical settings (diagnostic pathways). The visual structure makes complex multi-step logic auditable at a glance.
- What is the difference between a decision node and a leaf node?
- A decision node (drawn as a diamond) is an internal node where a question is asked or a condition is tested. Each branch leaving a decision node corresponds to one possible answer or outcome of that test. A leaf node (drawn as a rounded rectangle or oval) is a terminal node — it represents a final outcome, action, or classification and has no outgoing branches. A correctly formed decision tree alternates between decision nodes and branches until every path terminates at a leaf.
- How are machine learning decision trees different from business decision trees?
- A machine learning decision tree is a trained statistical model: splits are chosen algorithmically (using metrics like information gain or Gini impurity) to minimise prediction error on training data. The resulting tree classifies new data points by routing them through learned splits. A business decision tree is a manually constructed diagram that encodes expert knowledge or policy rules — for example, a loan approval policy or a customer support routing script. Both use the same branching visual structure, but one is inferred from data and the other is authored by domain experts.
- When should I use a decision tree instead of a flowchart?
- Use a decision tree when your primary goal is to model a classification or routing problem — every path through the diagram ends at a discrete outcome and the branching logic is the main content. Use a flowchart when your goal is to document a process with sequential steps, loops, and possibly multiple actors. A decision tree has no loops and no process steps between decisions; a flowchart can have both. In practice, many business processes combine the two: a flowchart describes the overall workflow, while embedded decision diamonds model the branching logic within it.
- What is the difference between a decision tree and a flowchart?
- A flowchart (ISO 5807) is a general-purpose process diagram that includes start/end terminators, process rectangles (actions), decision diamonds, data parallelograms, and connectors — it can model loops, parallel paths, and multi-actor handoffs. A decision tree is a specialised subset focused exclusively on decision branching: every node is either a decision or a terminal outcome, and there are no loops. Decision trees are acyclic by definition; flowcharts are not. Use a flowchart for processes; use a decision tree for classification logic.
- What are BPMN gateway types and when do I use them?
- BPMN 2.0 defines three gateway types for branching logic. An exclusive gateway (XOR, marked with an X) routes the process to exactly one outgoing path — the first condition that evaluates to true. An inclusive gateway (OR, marked with an O) routes the process to one or more paths simultaneously based on independent conditions. A parallel gateway (AND, marked with a +) activates all outgoing paths at once, with no condition. An event-based gateway routes based on which of several events occurs first (a timer, a message, or a signal). For decision trees rendered in BPMN, the exclusive gateway is the correct choice — only one outcome applies per decision.
- What are best practices for building a decision tree?
- Keep each decision binary (Yes/No or True/False) when possible — ternary splits are harder to read and maintain. Label every branch with its condition, not just "Yes" and "No". Name leaf nodes with specific outcomes, not generic labels like "End". Balance depth against readability: a tree deeper than five levels is usually better split into two linked diagrams. Validate that every combination of conditions leads to exactly one leaf — gaps cause routing errors and overlaps cause ambiguity. For machine learning trees, prune aggressively to avoid overfitting.