Decision table
A decision table is the right shape when a decision depends on several inputs at once. Drawn as a tree it explodes; written as a table it stays one screen.
Capable includes a DMN editor, so the table you author is a real DMN decision with hit policies and FEEL expressions, not a picture of a spreadsheet.
#When to reach for one
Pricing, eligibility and discount rules with several inputs.
Anything a business analyst will maintain after you have moved on.
Decisions that will later be executed by a rules engine.
#How to draw it in Capable
Route | Use when |
|---|---|
DMN editor | Always, for a real decision table. |
A page table | Only when the rules will never be executed or validated. |
#Hit policies worth knowing
Policy | Meaning |
|---|---|
Unique | Exactly one row may match. Two matches is an error, and that is useful. |
First | Rows are ordered; the first match wins. |
Collect | Every match contributes, optionally summed or counted. |
Any | Several rows may match, but they must agree on the output. |
Unique is the safest default. It turns overlapping rules into a visible error rather than a silent, order-dependent answer.
#A few things that catch people out
The hit policy is not decoration. Unique, First and Collect behave differently when two rows match.
FEEL expressions let a cell say [18..65] or not("UK"), which a plain table cannot.
A DMN table with one input column is a decision tree wearing a disguise.
#Related
Draw the unhappy path too.
