Decision trees vs flowcharts: which one fits the problem?

Decision trees and flowcharts both use boxes, arrows and questions, so they get treated as interchangeable. They are not. One describes a choice and the other describes a process, and the difference shows up in a single structural rule: whether paths are allowed to come back together.

Pick the wrong one and the diagram fights you. A process forced into a tree sprouts duplicated branches and cannot show a retry. A classification forced into a flowchart grows merge points and loops that make it hard to find your own case. This article explains the difference, draws one refund policy both ways, and ends with a table for choosing.

The structural difference

A decision tree is a tree in the strict sense. It starts at a single root question. Every node has exactly one parent. Branches split and keep splitting until they reach leaves, and a leaf is an outcome. Paths never rejoin and never loop. Follow any route from the root and you get one complete case: these answers lead to this result.

A flowchart is a general directed graph. It has a start and one or more ends, and in between, paths can split at decisions, merge back into a shared step, and loop back to repeat earlier work. Follow a route and you get a sequence of things that happen, possibly more than once.

Everything else follows from this. Because a tree cannot merge, any outcome reachable by two routes must be drawn twice. Because a tree cannot loop, it cannot express "try again". Because a flowchart can merge, it is compact, but a reader cannot point at a single box and say which combination of answers led there.

What each diagram is for

A decision tree answers a classification question. Given some facts, which bucket does this case fall into? Eligibility rules, troubleshooting guides, triage, product selectors and diagnostic questionnaires all have this shape. Time is not really involved: the questions could be asked in any order in principle, and the tree just fixes a sensible one.

A flowchart answers a process question. What happens, in what order, and what happens when something goes wrong? Order fulfilment, approvals, onboarding and support escalation all have this shape. Time matters, steps do work, and the same step can be reached by several routes or repeated.

In decision analysis there is a more formal kind of tree, with chance nodes for uncertain events and values attached to each outcome, used to compare options under uncertainty. This article is about the everyday kind: a structured set of questions that leads to an answer. The structural argument applies to both.

Worked example: one refund policy, drawn both ways

Take a shop's refund policy. Items returned within 30 days are eligible. Outside 30 days, a manager can approve an exception. Eligible items in resaleable condition get a full refund; damaged items get a partial refund. Anything not eligible is declined with an explanation.

As a flowchart

The flowchart starts at "Refund requested" and asks "Within 30 days?". Yes goes straight to the condition check. No goes to "Manager approves exception?", where Yes merges into the same condition check and No ends at "Declined with explanation". After the condition check, the refund is approved, the payment is returned to the original method and the customer is notified.

The merge is the efficiency. The condition check, the approval and the payment are drawn once and shared by both routes. The flowchart also carries steps that have nothing to do with the decision, such as returning the payment and notifying the customer, because a process has work in it and not only questions. In this version, the full-or-partial split would be a third decision after the condition check.

As a decision tree

Now draw the same policy as a tree. The root is "Within 30 days?". Because a tree cannot merge, the condition question has to appear under both the Yes branch and the exception's Yes branch.

Within 30 days?
├─ Yes → Item in resaleable condition?
│        ├─ Yes → Full refund
│        └─ No  → Partial refund
└─ No  → Manager approves exception?
         ├─ Yes → Item in resaleable condition?
         │        ├─ Yes → Full refund
         │        └─ No  → Partial refund
         └─ No  → Decline with explanation

Five leaves, three of them distinct outcomes. The condition sub-tree is duplicated. In return, every leaf is a complete statement of a rule. Point at any leaf and read upward: "over 30 days, exception approved, item damaged: partial refund". A customer service agent on the phone can walk this tree with a customer without understanding anything about payment processing.

Notice what the tree leaves out. There is no "Return payment to original method" and no "Customer notified". Those are steps in a process, and they happen the same way whichever leaf you reach. The tree is only the rule. That is why the two diagrams can coexist: the flowchart's condition check and approval can stand in for the tree.

The same rule as a decision table

There is a third form worth knowing when the rule is what matters. A decision table lists conditions down one side and every combination of answers across the other, with the outcome for each. It makes gaps and contradictions obvious, because every combination has a column whether or not anyone thought about it.

Writing the table raises questions the diagrams did not. Should an approved exception for a damaged item really get the same partial refund as an in-window damaged item? The table puts those two rows next to each other, which is often how policy gaps get noticed. Trees suit people looking up their own case; tables suit people checking that the rule is complete.

When a decision tree fits

• The goal is to reach an answer, not to describe work being done.
• There are no retries. Once a question is answered, it stays answered.
• Outcomes are few and do not need to be shared between many branches.
• The reader is looking for their own case and benefits from one question at a time.
• You want each path to be readable as a standalone rule, for training or for audit.

Troubleshooting guides are the classic fit. "Does the device power on? Is the light green? Does a restart help?" Each answer narrows the case until a leaf names the fix. If the tree starts repeating the same sub-tree three or four times, that is the signal to stop and reconsider.

Order the questions with care. Put first the question that removes the most cases or that the reader can answer most easily, so most people reach a leaf quickly. A tree that opens with an obscure technical question loses readers at the root, however correct the rest of it is.

When a flowchart fits

• Steps do work, not only ask questions.
• Something can fail and be retried, or rework can send the case back.
• Several routes lead to the same next step.
• Order and timing matter, including waiting for something.
• Handoffs between people or teams are part of the story.

Order fulfilment shows the loop problem clearly. A backorder waits and then asks the stock question again. A tree can only fake this by unrolling the loop: in stock now, in stock tomorrow, in stock the day after. The flowchart says it with one backward arrow.

A decision table for choosing

If you are unsure which to draw, answer these questions about the problem in front of you.

Two warning signs catch most wrong choices after the fact. A tree with duplicated sub-trees wants to be a flowchart, because the duplication is a merge it is not allowed to draw. A flowchart with no loops, no shared steps and nothing but questions leading to outcomes wants to be a tree, because it is a classification wearing a process's clothes.

Using both together

Many real problems contain a rule and a process, and the cleanest answer is to draw each in its own form. The flowchart carries the sequence and gets one step that stands for the rule. The tree carries the rule and nothing else.

In the refund example, the flowchart would read "Refund requested", then "Determine refund outcome", then a three-way branch to full refund, partial refund or decline, then the payment and notification steps. "Determine refund outcome" refers to the tree. If you use formal symbols, the predefined process shape, a rectangle with doubled sides, says exactly this: the step is defined elsewhere.

The split pays off when things change. If the policy moves from 30 days to 28, only the tree changes. If the shop starts refunding to store credit instead of the original payment method, only the flowchart changes. Each diagram has one reason to be edited, and different people can own each: the policy owner owns the tree, the operations lead owns the process.

Converting one into the other

To turn a flowchart's decisions into a tree, start at the first decision and copy every path forward, ignoring steps that only do work. Wherever two paths would merge, duplicate what follows instead. Stop each path at the first outcome. Loops cannot be converted; if you hit one, that part of the problem is a process and belongs in the flowchart.

To go the other way, look for identical sub-trees. Each set of duplicates becomes one shared step in the flowchart, with the branches that led to it merging there. Then add the steps that do the work around the decisions, which the tree never needed.

Drawing both in DiagramDock

DiagramDock has separate decision tree and flowchart diagram types, each with its own palette. For trees, "Arrange diagram" has a tree layout; for flowcharts, top-to-bottom and left-to-right layouts keep the main path straight. Layout only runs when you ask, and one undo restores every position. Flowcharts also get quick-add, one-click Yes and No branch labels, and a suggestions panel that flags unlabelled branches and unreachable steps.