# 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 [Value stream mapWhere the time actually goes.](https://help.gocapable.com/diagrams/value-stream-map.html) [User flow diagramScreen by screen, including the dead ends.](https://help.gocapable.com/diagrams/user-flow-diagram.html) [ExamplesWorking diagrams you can copy.](https://help.gocapable.com/diagrams/examples.html) --- _Draw the unhappy path too._