Decision Tree

A Decision Tree is a visual rule type built directly into DecisionRules. Think of it as a flowchart that lives inside your workspace — you define IF/THEN/ELSE blocks, nest them as deep as you need, and the engine walks the tree at runtime to produce a result. It's purpose-built for decisions that branch: approval logic, routing, eligibility checks, risk scoring, or any process where the next step depends on the answer to the previous one.

Decision Trees work best when the path through a decision depends on intermediate answers — approval workflows, eligibility checks, risk classification, dynamic pricing logic, or any process where earlier conditions determine which later conditions even matter. If your team describes the logic as first we check X, then depending on that we check Y or Z, a Decision Tree captures that naturally.

Use a Decision Tree when your logic branches — when the path through the decision depends on the outcome of earlier conditions. Decision Trees shine for sequential, multi-level reasoning where one answer unlocks the next question. Use a Decision Table when your logic is parallel — when you're evaluating many combinations of inputs against a flat set of rules and returning a result. If your logic reads more like a flowchart than a spreadsheet, Decision Tree is the right fit.

Decision Trees export and import as JSON — this captures the full rule definition including your input/output model, all blocks, and version metadata.

There's no spreadsheet-style data to import here.

Yes. Use the Download PDF button in the designer's bottom bar to download a visual snapshot of your tree. This is useful for sharing logic with stakeholders, getting sign-off from business teams, or attaching the decision flow to documentation — no DecisionRules account required to read it.

Any rule type in your workspace can call a Decision Tree using the built-in SOLVER function — Decision Tables, Scripting Rules. The most common pattern is wiring a Decision Tree as a node inside a Flow, where it handles the branching logic as one step in a larger automated process.

Yes — but the recommended pattern is to handle that orchestration in a Flow. There, you can sequence rules in any order: run a Lookup Table to fetch reference data, pass the results into a Decision Tree, then hand off to a Scripting Rule for further processing. Each rule stays focused on one job, and the Flow connects them.

Calling other rules directly from inside a Decision Tree is possible by using SOLVER function, but using a Flow gives you better visibility and control over how rules interact.

Yes. Because any rule can call a Decision Tree via SOLVER, the same tree can power logic across multiple rules or Flows. You maintain the branching logic in one place, and every caller automatically gets any updates you publish.

Use an ELSE block. The ELSE block is triggered whenever none of the preceding IF conditions in the same level are satisfied. It's your catch-all — the fallback path for any input that doesn't match a defined branch. Without an ELSE block, inputs that don't match any condition simply produce no output for that branch. Always add an ELSE block when you need a guaranteed response for every possible input.

Yes — and there are two types of history. Rule history is auto-saved every time you click Save, capturing your changes as you work. You can browse and restore any auto-save at any time. Versions are manual snapshots you create explicitly when making bigger changes — you can name them, compare them, and roll back with one click. Both give you a full safety net for your logic.

Permissions are fully customizable at multiple levels — space, account, team, and roles. You can grant edit access to specific users, restrict others to read-only, or set up approval workflows for production changes.

See our documentation for how to configure granular access control.

Yes. Use the Management API to automate your Decision Tree workflows — create rules, update logic, publish new versions, or trigger changes based on events in your application, all without touching the UI. This is ideal for automated deployment pipelines or keeping rules in sync with an external source of truth.

See our Management API documentation for details.

Let the business logic guide you, not an arbitrary limit. Nesting is powerful, but very deep trees can become hard for teammates to audit and maintain. If you find yourself beyond five levels of nesting, consider whether part of the logic belongs in a separate rule — a sub-tree called from a Flow — rather than all in one tree. Clarity beats compactness.

Split by concept, not by size. Each Decision Tree should model one decision — eligibility, routing, risk classification — with a clear input and a clear output. If your tree is making two unrelated decisions at once, that's a signal to split. Smaller, focused trees are easier to test, easier to explain to stakeholders, and easier to reuse across different Flows.

Three things: a clear input/output model defined before you start building, consistent branch naming that mirrors how the business talks about the decision, and an ELSE block at every level where an unmatched input is possible. Test with real-world edge cases — not just the happy path — before publishing. Use Debug Mode to confirm the engine is walking the tree exactly as you intended.