Decision table

What is a decision table?

A decision table sets out business logic as a grid: each row is a rule, the condition columns say when the rule applies, and the outcome columns say what happens. It suits decisions with several criteria at once, such as which discount applies, which approval level a request needs, or how a case should be routed.

Compared with a long chain of if-statements in code, a table makes it easier to see whether two rules overlap or whether some combination of inputs is not handled at all.

DMN, short for Decision Model and Notation, is a standard maintained by the Object Management Group that defines a notation for decision tables. DMN also specifies how a table behaves when more than one rule matches, through a hit policy.

How a decision table is built

The inputs are the facts you decide on. For a purchase approval those might be the amount, the cost type, and the requester's role. The outputs are the results, such as the required approval level.

A small rule set written out in words:

• Amount up to 1,000 euro and a routine cost: team lead.

• Amount above 1,000 up to 10,000 euro: department manager.

• Amount above 10,000 euro: director and finance.

• Any amount, new supplier: extra supplier check.

The last rule can match at the same time as an amount rule. The table therefore has to say whether both outputs apply, whether one rule wins, or whether the combination is rejected as a conflict.

Hit policies

A hit policy decides what happens when several rules match the same input. DMN defines a set of them. Under Unique, exactly one rule may match, and any overlap raises an error. Under First, the first matching rule in row order wins, which makes the ordering of rows part of the logic.

Collect gathers the results of every matching rule, and can sum them, count them, or take the minimum or maximum. Priority picks one outcome according to a ranked list of output values.

Choose a policy that matches the business meaning. Do not reach for First to paper over overlap you have not thought through. If exactly one route is meant to apply, an error on overlap is often safer than a silent pick.

A worked example

An insurer routes claims on the amount, whether there is bodily injury, and whether the documents are complete. A decision table returns one of Automatic, Standard review, Specialist, or Request documents.

Missing documents always return Request documents. Small complete claims with no injury can continue automatically. Bodily injury goes to a specialist, even on a low amount. A workflow engine calls the decision and creates the right task. The table decides the route, but it does not track how long that task then sits open.

Every outcome is stored with the rule id and the table version, so a colleague can later see why a claim ended up with a specialist.

Decision table versus decision tree and rules engine

A decision tree lays out an order of questions and branches, which helps in a conversation or a diagnosis. A decision table shows combinations of criteria more compactly and makes it more systematic to check that every case is covered.

A business rules engine executes rules. A decision table is one way to model and maintain those rules; not every engine uses DMN, and not every table has to be executed automatically. For a single stable condition a table is overkill. It earns its place once combinations, exceptions, and changing policy become hard to read in plain code, close to the kind of logic a validation rule captures at a smaller scale.

What to watch out for with decision tables

Cover the gaps. Test every row, every boundary value, and combinations where no rule should match. Decide explicitly whether 1,000 euro belongs to the first or the second rule, and how blank values are treated.

Version the table. Give it an owner, an effective date, and a reason for each change. Run a new version against past cases to catch route changes you did not expect.

Readable is not the same as correct. A clear table makes rules easier to discuss, but it does not prove they are fair or legally sound. Review the content and the consequences of the decision, not only its shape.