Decision Table

Overview

A Decision Table is a Logic Block that accepts one or more inputs and produces one or more outputs using a structured, tabular approach to decision-making. Decision Tables provide a clear, visual way to define business decisions—combinations of conditions that determine specific outputs.

Decision Tables are ideal when you have:

• Multiple conditions that determine an outcome
• Several decisions that need to be evaluated
• Business logic that stakeholders need to review and understand
• Decisions that change frequently and need easy maintenance

The tabular format makes Decision Tables exceptionally readable. Business users can review the decisions directly, understanding exactly what conditions lead to what outcomes without deciphering code or complex expressions.

How Decision Tables Work

A Decision Table contains one or more decisions. Each decision represents a row in the table that defines a specific combination of conditions and the outputs to produce when those conditions are met.

When a Decision Table is evaluated:

1. Each decision is evaluated in sequence (top to bottom)
2. When a decision's conditions match the inputs, that decision "fires"
3. The outputs defined by that decision are returned
4. First-match wins: Once a decision fires, evaluation stops

This first-match behavior means the order of decisions matters. Place more specific decisions before more general decisions to ensure they have a chance to fire.

Structure

A Decision Table consists of:

Component	Description
Name	Unique identifier for the Decision Table
Description	What business logic the table encodes
Inputs	Condition columns (what we evaluate)
Outputs	Result columns (what we produce)
Decisions	Rows defining condition-output combinations

Inputs (Condition Columns)

Each input becomes a condition column in the table. For each decision, you specify how the input should be evaluated:

Condition Type	Description	Example
Exact Match	Input equals a specific value	CustomerTier = "Gold"
Range	Input falls within a range	>= 1000 AND < 5000
Comparison	Input compared to a value	> 90
Any	Matches any value (wildcard)	- (dash)

Outputs (Result Columns)

Each output column specifies what value to produce when a decision fires. A Decision Table can have multiple outputs, and each decision specifies values for all outputs:

• Literal values: 15, "Approved", true
• Calculated expressions: OrderAmount * 0.10
• References to inputs: Copy input value to output

Example: Discount Rate Decision Table

Name: DetermineDiscountRate

Inputs:

• CustomerTier (Option Set): Gold, Silver, Bronze, Standard
• OrderAmount (Money): Total order value
• IsFirstOrder (Boolean): Whether this is customer's first order

Outputs:

• DiscountPercent (Decimal): Discount percentage to apply
• DiscountReason (String): Explanation of discount

Decisions:

#	CustomerTier	OrderAmount	IsFirstOrder	→ DiscountPercent	→ DiscountReason
1	Gold	>= 10000	-	20	"Gold tier + high value order"
2	Gold	>= 5000	-	15	"Gold tier + medium value order"
3	Gold	-	-	12	"Gold tier standard discount"
4	Silver	>= 10000	-	15	"Silver tier + high value order"
5	Silver	>= 5000	-	10	"Silver tier + medium value order"
6	Silver	-	-	8	"Silver tier standard discount"
7	Bronze	>= 10000	-	10	"Bronze tier + high value order"
8	Bronze	-	-	5	"Bronze tier standard discount"
9	-	-	true	10	"First order discount"
10	-	>= 10000	-	5	"High value order discount"
11	-	-	-	0	"No discount applicable"

Evaluation Example:

For inputs: CustomerTier = "Silver", OrderAmount = $7,500, IsFirstOrder = false

1. Decision 1: CustomerTier is not "Gold" → Skip
2. Decision 2: CustomerTier is not "Gold" → Skip
3. Decision 3: CustomerTier is not "Gold" → Skip
4. Decision 4: CustomerTier is "Silver", but OrderAmount is less than 10000 → Skip
5. Decision 5: CustomerTier is "Silver" ✓, OrderAmount >= 5000 ✓ → MATCH

Output: DiscountPercent = 10, DiscountReason = "Silver tier + medium value order"

Example: Approval Routing Decision Table

Name: DetermineApprovalRoute

Inputs:

• RequestType (Option Set): Purchase, Travel, Training, Equipment
• Amount (Money): Request amount
• Department (String): Requesting department

Outputs:

• ApproverRole (String): Who should approve
• RequiresVPApproval (Boolean): Whether VP must also approve
• SLADays (Integer): Days to complete approval

Decisions:

#	RequestType	Amount	Department	→ ApproverRole	→ RequiresVPApproval	→ SLADays
1	Purchase	>= 50000	-	"Finance Director"	true	5
2	Purchase	>= 10000	-	"Finance Manager"	false	3
3	Purchase	-	-	"Department Manager"	false	2
4	Travel	>= 5000	-	"Finance Manager"	true	3
5	Travel	-	"Executive"	"CEO"	false	1
6	Travel	-	-	"Department Manager"	false	2
7	Training	>= 10000	-	"HR Director"	true	5
8	Training	-	-	"HR Manager"	false	3
9	Equipment	>= 25000	-	"IT Director"	true	5
10	Equipment	-	-	"IT Manager"	false	2

Best Practices

Order Decisions from Specific to General

Since the first matching decision wins, place specific decisions before general ones:

✅ Good:
  Decision 1: CustomerTier = "Gold" AND OrderAmount >= 10000 → 20%
  Decision 2: CustomerTier = "Gold" → 12%

❌ Bad:
  Decision 1: CustomerTier = "Gold" → 12%
  Decision 2: CustomerTier = "Gold" AND OrderAmount >= 10000 → 20%  (Never fires!)

Always Include a Default Decision

The last decision should match any input combination to ensure the table always produces output:

| # | CustomerTier | OrderAmount | → DiscountPercent |
|---|--------------|-------------|-------------------|
| ... | ... | ... | ... |
| 11 | - | - | 0 |  ← Default: matches everything

Keep Tables Focused

Each Decision Table should handle one business decision. If you find a table growing beyond 15-20 decisions, consider breaking it into multiple focused tables.

Use Meaningful Outputs

Each decision should produce clear, self-documenting output values that help reviewers understand the business logic.