What is a decision table?

What a decision table is

A decision table is one of the oldest and most useful ways to write down business rules. Instead of long paragraphs or nested if statements, you lay the rule out as a grid. Each column on the left is a condition. Each column on the right is an outcome. Each row is one rule.

Anyone who has used a pricing grid, a shipping rate card or an approval matrix has already used a decision table. The format works because it is easy to scan. You can see every combination at once, spot a missing case and check a single row without reading the rest.

Decision tables sit comfortably between the business and IT. A finance manager can read one and say whether it matches the policy. A developer or a rules engine can apply it without interpretation. That shared, unambiguous view is why they are used so widely in requirements documents, policy manuals and software testing, and why most rules tools support them in some form.

The parts of a decision table

Whatever tool you use, decision tables share the same building blocks:

• Conditions (inputs): the facts the decision depends on, such as order value, customer tier or country.
• Condition entries: the values or ranges in each cell, such as "under 1,000", "Tier A" or "any".
• Outcomes (outputs): what the decision returns, such as a discount, an approver or approve or refer.
• Rules (rows): one combination of condition entries and its outcome.
• Hit policy: what happens if more than one row matches, for example use the first match, or the only match, or collect all matches.

A worked decision table example

The example table on this page sets delivery charges for a wholesaler. The conditions are the customer tier and the order value; the outcome is the delivery charge. To decide, you take the customer's tier and the order value and find the matching row.

Written as prose, the same policy would take a paragraph and invite misreading. As a table, a new starter can apply it on day one, and a manager can see at a glance that Tier B orders between 500 and 1,000 cost 15 to deliver. The table also makes it obvious if a combination has been missed, which is one of the most common sources of error when rules live in code or email.

Notice how the rows are arranged. Tier A has a single row with "any" in the order value column, because the outcome does not depend on value for those customers. Tier B and Tier C are split into bands that do not overlap and together cover every possible value. No gaps and no overlaps is the property that makes a table safe to automate: every order matches exactly one row.

Now imagine the business decides that Tier C orders between 500 and 999.99 should cost 20 to deliver. In a table, that is one new row and one changed row, and anyone can see exactly what moved. Buried in code or a nested spreadsheet formula, the same change is easy to get subtly wrong. It is also easy to test: take a handful of past orders from each band, run them through the new table and check the charges match what you expect before the change goes live.

When to use a decision table

Decision tables are a great fit when a decision depends on a few conditions that combine in regular ways, and when the outcome is a value or a category. Typical uses include:

• Pricing bands, discount limits and delivery charges.
• Approval limits by amount, cost centre and category.
• Risk ratings by country, sector or supplier type.
• Eligibility criteria with a small number of tests.
• Test design, where each row becomes a test case to check a system against.

Limits, and good practice

Decision tables get unwieldy when too many conditions combine, because the number of rows can grow quickly. They also struggle with decisions that need several steps, such as look up a limit, add up the lines, then compare, or that loop over a list of items. In those cases it is better to split the decision into steps and use smaller tables inside them.

A few habits keep tables reliable. Make sure every combination is covered, including an explicit default row. Avoid overlapping rows, or agree a clear hit policy. Keep numbers in the table, not in formulas, so changes are visible. And test the table with real examples before anyone relies on it.

Decision tables in software

Formal standards also exist. The Decision Model and Notation (DMN) standard, for example, defines decision tables with named hit policies so they can be shared between tools. You do not need a standard to get value from a decision table, but it is useful to know the vocabulary when comparing products.

Many teams keep decision tables in spreadsheets, which works until the table needs to be called by a system, versioned or audited. Decision table software and rules engines hold the table in a controlled place, apply it automatically and record which row was used.

In Condexa, decision tables live as lookup tables that business users own. A workflow looks up the right row, combines it with other checks, and returns the answer to any system that asks, with a trace showing the row that was used. If your tables currently live in Excel, see replacing spreadsheet decision logic.