Business Rule Solutions
Decision Table Template: Examples & Guide
Use a decision table template with practical examples, Excel instructions, and steps to create, review, and manage business rules.
A business policy may look simple until several conditions determine the outcome.
A purchasing request might require different approvals based on its value, department, and urgency. A customer may qualify for a discount only when their account status, purchase amount, and product category meet specific criteria.
Writing every possible combination as a separate paragraph can make the rules difficult to understand and maintain.
A decision table template solves this problem by organizing related business rules into a structured format. It shows which conditions apply, how they interact, and what outcome should follow.
Decision tables help business analysts, process owners, and development teams examine decision logic before implementing it in workflows or rules engines.
This guide includes:
- A reusable decision table template.
- A complete business rules example.
- Instructions for creating a decision table in Excel.
- A step-by-step method for building decision tables.
- Examples involving purchasing, customer discounts, and request routing.
- Guidance for identifying missing, overlapping, and conflicting rules.
- A checklist for reviewing decision tables before implementation.
The examples are fictional and designed to demonstrate practical business-rule analysis.
What Is a Decision Table?
A decision table is a structured representation of business rules that maps combinations of conditions to corresponding actions or outcomes.
Each rule describes what should happen when a particular combination of conditions is satisfied.
For example, a company may approve a customer discount based on two conditions:
- Whether the customer has an active membership.
- Whether the purchase meets a minimum order amount.
A decision table organizes the possible combinations into rows and assigns an outcome to each one.
| Active membership | Order is at least $200 | Discount |
|---|---|---|
| Yes | Yes | 10% |
| Yes | No | 5% |
| No | Yes | 0% |
| No | No | 0% |
Illustrative business policy.
Instead of interpreting multiple disconnected statements, stakeholders can review the complete decision logic in one place.
Decision tables are particularly useful when several business rules depend on the same inputs.
According to IBM's documentation on decision tables, this format organizes rule conditions and actions so related decision logic can be reviewed together.
What Are the Main Components of a Decision Table?
Most business-rule decision tables contain four essential elements.
| Component | Meaning | Example |
|---|---|---|
| Rule ID | Identifier for a decision rule | R-001 |
| Condition | Information evaluated by the rule | Active membership |
| Condition value | The value required for that rule to apply | Yes |
| Action or outcome | The result when conditions match | Apply 10% discount |
More advanced tables may include source references, effective dates, rule owners, priorities, and implementation notes.
These additional fields make the table easier to maintain when business policies change.
Free Decision Table Template for Business Rules
The following reusable decision table format works as a starting point for business analysts, product teams, and process owners.
It can be copied into Microsoft Excel, Google Sheets, or a document.
Blank Decision Table Template
| Rule ID | Condition 1 | Condition 2 | Condition 3 | Expected outcome |
|---|---|---|---|---|
| R-001 | ||||
| R-002 | ||||
| R-003 | ||||
| R-004 | ||||
| R-005 |
Replace the generic condition headings with meaningful business inputs.
For example:
- Customer status.
- Order amount.
- Product eligibility.
The outcome column should identify the decision result, not simply describe the next technical screen or button.
How to Complete the Template
Start by identifying one decision question.
For example:
"What discount should this customer receive?"
Next, identify the facts that determine the answer.
In this example:
- Customer membership status.
- Order value.
Then identify every valid outcome.
Finally, create the rules required to cover the relevant combinations.
A completed table should make it possible to answer the decision question consistently using the approved business criteria.
Excel-Compatible Decision Table Template
Copy the following CSV into Excel or Google Sheets.
Rule ID,Condition 1,Condition 2,Condition 3,Expected Outcome
R-001,,,,
R-002,,,,
R-003,,,,
R-004,,,,
R-005,,,,
This is a reusable analysis template, not an executable rules-engine file.
Different rules engines may require specific spreadsheet structures, expression syntax, and additional configuration.
Decision Table Example With Solution
Consider a fictional company that requires different purchase approvals depending on the request amount and whether the request is urgent.
The approved policy for this example states:
- Standard purchases up to $1,000 require supervisor approval.
- Standard purchases above $1,000 and up to $10,000 require department manager approval.
- Standard purchases above $10,000 require finance director approval.
- Urgent purchases must follow a separate emergency purchasing procedure.
The business decision is:
Which approval path applies to a purchase request?
Step 1: Identify the Conditions
Two conditions affect the approval path:
- Purchase amount.
- Whether the request is urgent.
The purchase amount has three defined ranges:
- $1,000 or less.
- Greater than $1,000 and up to $10,000.
- Greater than $10,000.
Urgency has two permitted values:
- Yes.
- No.
Step 2: Identify the Outcomes
The possible outcomes are:
- Supervisor approval.
- Department manager approval.
- Finance director approval.
- Emergency purchasing procedure.
Step 3: Create the Decision Table
| Rule ID | Purchase amount | Urgent? | Required approval path |
|---|---|---|---|
| PUR-001 | $1,000 or less | No | Supervisor |
| PUR-002 | Greater than $1,000 and up to $10,000 | No | Department manager |
| PUR-003 | Greater than $10,000 | No | Finance director |
| PUR-004 | Any valid amount | Yes | Emergency purchasing procedure |
Illustrative example. All purchase amounts are assumed to be valid, nonnegative numbers. The emergency procedure is a separate approved process; this table does not define or waive approvals within it.
Step 4: Evaluate Example Inputs
| Test purchase | Urgent? | Matching rule | Expected outcome |
|---|---|---|---|
| $500 | No | PUR-001 | Supervisor |
| $1,000 | No | PUR-001 | Supervisor |
| $4,500 | No | PUR-002 | Department manager |
| $10,000 | No | PUR-002 | Department manager |
| $12,000 | No | PUR-003 | Finance director |
| $12,000 | Yes | PUR-004 | Emergency purchasing procedure |
This table provides a clear answer for every valid combination of the defined input ranges and urgency status.
It also avoids overlapping rules within the stated model.
Step 5: Identify Questions Before Implementation
A complete-looking decision table may still depend on undefined business terminology.
For example:
- Does the purchase amount include tax and shipping?
- What qualifies as urgent?
- Who is authorized to declare a request urgent?
- Can approval authority be delegated?
- What happens if the amount is missing or invalid?
- Which version of the purchasing policy applies?
These questions should be resolved before the table is approved for operational use.
A decision table makes business logic visible, but it does not automatically make that logic correct.
How to Create a Decision Table: 7 Steps
Creating a reliable decision table begins with understanding the decision—not filling a spreadsheet with possible combinations.
Step 1: Define One Business Decision
Write the question the table must answer.
Examples include:
- Which approval level is required?
- Is the customer eligible for a discount?
- Which review team should receive this request?
- Which service category applies?
A table becomes harder to understand when it attempts to answer several unrelated business questions at once.
If necessary, separate complex decisions into smaller tables.
Step 2: Identify Relevant Business Rules
Review the policies and requirements that govern the decision.
Possible sources include:
- Approved policy documents.
- Standard operating procedures.
- Business requirements.
- Existing decision logic.
- Subject matter expert knowledge.
Do not assume that existing application behavior always represents current approved policy.
If you need a structured approach to identifying and clarifying rules, see our guide to business rules analysis.
Step 3: Define the Input Conditions
Identify the facts that can change the decision outcome.
For a discount decision, relevant conditions might include:
- Membership status.
- Order amount.
- Product eligibility.
Avoid adding inputs that do not influence the result.
Each condition should have an understandable definition and a defined set or range of possible values.
Step 4: Define Every Possible Outcome
List the decisions the table may return.
For example:
- Eligible.
- Not eligible.
- Manual review required.
Make sure the outputs are distinguishable and meaningful to the business.
A result such as "Handle appropriately" is too vague to support consistent decisions.
Step 5: Create the Rule Rows
Create a row for each necessary combination of conditions and outcomes.
For the membership example, two yes/no conditions produce four logical combinations.
However, not every decision requires every possible combination to appear as a separate row.
Where several combinations produce the same result, they may be consolidated using an appropriate wildcard or condition range, provided the underlying semantics remain clear.
Step 6: Check for Missing or Overlapping Rules
Examine whether valid input combinations can produce:
- No matching rule.
- More than one matching rule.
- Conflicting outcomes.
These problems must be addressed according to the intended decision semantics.
A table designed to return exactly one result should not contain overlapping rules that produce different results.
Step 7: Validate and Approve the Table
Ask the appropriate business owners to confirm:
- The conditions are correct.
- Outcomes match approved policy.
- Exceptions are understood.
- Boundaries are precise.
- Important scenarios are covered.
- Rule ownership and effective dates are clear.
A table should be validated before it is implemented in an operational system.
How to Create a Decision Table in Excel
Microsoft Excel is useful for documenting decision tables because business analysts are generally familiar with spreadsheet-based information.
You do not need a specialized rules engine to create a table for analysis and stakeholder review.
Recommended Excel Columns
For a basic business rules decision table, organize the columns as follows:
| Column | Heading |
|---|---|
| A | Rule ID |
| B | Condition: Membership Status |
| C | Condition: Order Value |
| D | Outcome: Discount |
| E | Business Owner |
| F | Approval Status |
Each row represents one decision rule.
Example Excel Decision Table
| Rule ID | Membership status | Order amount | Discount | Owner | Status |
|---|---|---|---|---|---|
| DIS-001 | Active | At least $200 | 10% | Sales Operations | Draft |
| DIS-002 | Active | Below $200 | 5% | Sales Operations | Draft |
| DIS-003 | Inactive | Any valid amount | 0% | Sales Operations | Draft |
This example assumes valid nonnegative order amounts, a defined membership classification, and no separate promotional restrictions.
The word "Draft" is intentional. The table has not yet been approved by the relevant business authority.
Practical Excel Setup
- Create a new workbook.
- Enter descriptive condition and outcome headings.
- Add one row for each rule.
- Use data validation to restrict category values where appropriate.
- Apply consistent formatting to ranges and amounts.
- Add columns for ownership, version, and approval status.
- Review combinations for gaps and overlaps.
- Protect approved reference information from unauthorized changes as required.
Excel can serve as a useful rule-analysis register.
However, an Excel table does not automatically become an executable decision service.
Some platforms support spreadsheet-based rule definitions, but the expected workbook structure is product-specific. IBM's spreadsheet decision table documentation describes one example of a platform-specific format.
Decision Table Examples in Business Analysis
Decision tables can be used in many business functions.
The following examples show how different decision conditions can be represented without relying on long procedural descriptions.
Example 1: Customer Discount Decision Table
Consider a retailer with this fictional policy:
- Active members receive 10% off eligible orders of $200 or more.
- Active members receive 5% off eligible orders below $200.
- Inactive members receive no membership discount.
- Ineligible products receive no membership discount.
| Rule | Active member? | Eligible product? | Order value | Membership discount |
|---|---|---|---|---|
| D-001 | Yes | Yes | At least $200 | 10% |
| D-002 | Yes | Yes | Below $200 | 5% |
| D-003 | No | Any | Any valid amount | 0% |
| D-004 | Yes | No | Any valid amount | 0% |
Illustrative example. Order amounts must be nonnegative, membership and eligibility inputs must be known, and discount-stacking policies are outside this decision's scope.
Notice how conditions marked "Any" reduce unnecessary rule combinations.
The table still needs a defined treatment for invalid or missing values before automation.
Example 2: Support Request Routing
A software company needs to determine how incoming support requests should be routed.
Its fictional policy is:
- Security incidents go to the security response team.
- Non-security requests affecting production go to priority support.
- Other requests go to standard support.
| Rule | Security incident? | Production affected? | Routing outcome |
|---|---|---|---|
| S-001 | Yes | Any | Security response |
| S-002 | No | Yes | Priority support |
| S-003 | No | No | Standard support |
This model makes the precedence explicit: a security incident is routed to security response even if production is affected.
It also illustrates how a table can represent a business decision without defining the entire support workflow.
Example 3: Document Completeness Review
A fictional organization checks submitted applications.
| Rule | Required documents complete? | Submitted information valid? | Outcome |
|---|---|---|---|
| A-001 | Yes | Yes | Ready for review |
| A-002 | No | Any | Request missing documents |
| A-003 | Yes | No | Request correction |
This table has a single outcome for each combination of the two boolean inputs.
It does not determine whether an application is ultimately approved.
Instead, it answers a narrower question:
"Is the application ready for substantive review?"
Clear decision boundaries prevent a table from being used for purposes it was not designed to support.
Decision Table Format: Limited-Entry vs Extended-Entry
Business analysts commonly use different formats depending on the complexity of the conditions.
Limited-Entry Decision Table
A limited-entry table represents conditions with simple values, often Yes or No.
Example:
| Rule | Account active? | Payment received? | Outcome |
|---|---|---|---|
| R1 | Yes | Yes | Continue processing |
| R2 | Yes | No | Request payment |
| R3 | No | Yes | Account review |
| R4 | No | No | Account review |
This format is easy to inspect when each condition has a small number of possible states.
Extended-Entry Decision Table
An extended-entry table uses ranges, numbers, or other specific values.
Example:
| Rule | Order amount | Customer category | Outcome |
|---|---|---|---|
| R1 | Below $500 | Standard | Standard processing |
| R2 | At least $500 | Standard | Manager review |
| R3 | Any valid amount | Preferred | Priority processing |
This format can represent numeric thresholds and business classifications more compactly.
These are illustrative classifications, not formal customer policies.
The best decision table format depends on the complexity of the decision and the level of detail required.
How to Find Missing and Conflicting Decision Table Rules
One of the most valuable uses of decision tables is identifying logic that is difficult to detect in ordinary prose.
Missing Rule Example
Consider this incomplete table:
| Rule | Active member? | Order at least $200? | Discount |
|---|---|---|---|
| R1 | Yes | Yes | 10% |
| R2 | Yes | No | 5% |
| R3 | No | Yes | 0% |
What happens when a customer is not an active member and the order is below $200?
No row covers that combination.
That is a gap in the table.
For this fictional policy, the missing rule is:
| Rule | Active member? | Order at least $200? | Discount |
|---|---|---|---|
| R4 | No | No | 0% |
Adding R4 completes the defined set of combinations.
Overlapping Rule Example
Now consider:
| Rule | Active member? | Order amount | Discount |
|---|---|---|---|
| R1 | Yes | At least $100 | 5% |
| R2 | Yes | At least $200 | 10% |
A member placing a $250 order satisfies both rules.
If the business expects one discount, the table is ambiguous without a specified conflict-resolution policy.
A corrected table might be:
| Rule | Active member? | Order amount | Discount |
|---|---|---|---|
| R1 | Yes | At least $100 and below $200 | 5% |
| R2 | Yes | At least $200 | 10% |
Now the conditions do not overlap.
The team must still specify the outcome for orders below $100 if the table is intended to handle every valid member order.
Decision Table Completeness vs Consistency
Completeness asks whether the relevant valid input combinations have an intended outcome.
Consistency asks whether the rules avoid contradictory results under the chosen evaluation semantics.
A table can be complete but inconsistent.
It can also be consistent but incomplete.
Both properties matter when preparing decision logic for automation.
Decision Table vs Decision Tree
Decision tables and decision trees both help represent decisions, but they organize information differently.
| Feature | Decision table | Decision tree |
|---|---|---|
| Main structure | Rows and columns | Branching paths |
| Best use | Comparing combinations of conditions | Exploring sequential decisions |
| Strength | Compact view of related rules | Visual representation of branching logic |
| Common challenge | Large numbers of rule combinations | Complex trees with many branches |
| Typical use | Eligibility, approval, classification | Diagnostic or sequential decision paths |
Choose a decision table when the goal is to compare combinations of conditions in one structured view.
Choose a decision tree when the order and branching of questions are central to understanding the decision.
Neither format is universally better.
Complex decisions may use several representations together.
Decision Tables in Business Rules Management and DMN
In enterprise environments, decision tables can be more than documentation.
They can form part of a governed decision model used by a business rules engine or decision service.
The Object Management Group's Decision Model and Notation (DMN) provides a formal standard for modeling business decisions and decision logic.
DMN decision tables define inputs, rules, outputs, and how matching rules are evaluated.
What Is a Decision Table Hit Policy?
A hit policy specifies how the decision table should handle rules that match the same inputs.
Common examples include:
- Unique: No more than one rule may match.
- Any: Multiple rules may match only when they produce the same result.
- First: The first matching rule determines the result.
- Collect: Multiple matching results may be returned or aggregated according to the applicable configuration.
These policies have precise meanings in DMN and must not be treated as interchangeable.
For many business decisions, a Unique policy is a useful starting point when the requirement is to produce one unambiguous outcome.
However, the correct hit policy depends on the business decision's intended semantics.
A manually created Excel template is not automatically a compliant DMN model.
If the goal is executable decision automation, the final table should be reviewed against the target platform's supported notation and behavior.
Common Decision Table Mistakes
Starting With a Spreadsheet Instead of a Business Decision
The table should answer a defined question.
Without a clear decision, columns and conditions can expand without improving the model.
Using Undefined Business Terms
A condition such as "High-value customer" is not precise until the business agrees on the definition.
Ignoring Boundary Values
Numeric thresholds must define whether a boundary is inclusive or exclusive.
For example, "above $10,000" is different from "at least $10,000."
Assuming Rule Order Always Determines the Outcome
In some systems, rule order matters only under particular evaluation policies.
Do not rely on spreadsheet row order unless the intended decision semantics explicitly require it.
Hiding Exceptions in General Rules
Emergency approvals, legal exceptions, and special classifications may need separate documented decisions.
Failing to Check Coverage
Valid inputs should not unexpectedly fall outside the defined table.
Mixing Decisions With Workflow Activities
A decision table should primarily represent decision conditions and outcomes.
The sequence of operational tasks may be better represented through a process model.
Treating a Draft Table as Approved Policy
A well-formatted table can still contain inaccurate or unapproved business assumptions.
Business owners must validate the underlying rules.
Decision Table Review Checklist
Use this checklist before approving a decision table for business use.
Decision Definition
- One clear decision question is identified.
- The possible outcomes are documented.
- The scope of the table is understood.
Inputs and Conditions
- Input conditions have clear definitions.
- Valid values and numeric ranges are identified.
- Missing or invalid inputs have defined handling.
- Irrelevant conditions have been removed.
Rules and Coverage
- Each row expresses a meaningful decision rule.
- Boundary values are precise.
- Valid input combinations are covered.
- Conflicting overlaps have been addressed.
- The intended evaluation semantics are documented.
Governance
- The authoritative policy source is known.
- Business ownership is assigned.
- Exceptions are documented.
- Rule versions and effective dates are recorded.
- Necessary business approvals have been obtained.
Implementation Readiness
- Expected results are testable.
- Relevant scenarios have been reviewed.
- The table aligns with the intended target system.
- Technical and business stakeholders understand its limitations.
A decision table is ready for implementation only when its meaning and intended outcomes have been validated.
For a more detailed approach to generating test cases, see our separate article on decision table testing techniques and examples.
How RonBot Can Help Prepare Business Rules for Decision Tables
Creating a table is often the easy part.
The more difficult work involves identifying the correct business rules, clarifying ambiguous policy language, discovering exceptions, and determining which conditions actually control the decision.
A company may have its purchasing rules scattered across policy documents, procedures, spreadsheets, and employee knowledge.
Before those rules can be organized into a reliable decision table, someone must establish what they mean.
RonBot, from Business Rule Solutions, supports structured learning and analysis of business knowledge.
For example, professionals working on decision models can use AI-assisted business-analysis methods to explore:
- Candidate rules from policies and procedures.
- Unclear terminology.
- Missing conditions.
- Potential rule conflicts.
- Questions for subject matter experts.
- Draft rule statements requiring validation.
These activities can support the preparation of rules before they are represented in a formal decision model.
RonBot is not a substitute for a decision table execution engine, formal rule approval, or required technical testing.
Before Building a Decision Table, Clarify the Rules
A well-designed decision table depends on the quality of the underlying business knowledge.
If different departments interpret a policy differently, placing those interpretations into a spreadsheet will not resolve the disagreement.
The organization must first identify the authoritative rules, clarify exceptions, and validate intended outcomes.
Teams exploring structured business knowledge analysis can explore RonBot to learn how it may support their preparation for decision modeling and automation.
Frequently Asked Questions
What is a decision table template?
A decision table template is a reusable table structure that organizes business conditions and corresponding outcomes. It helps analysts document and compare decision rules consistently.
How do you create a decision table?
Define the decision, identify relevant inputs, list expected outcomes, create the rule combinations, check for gaps and overlaps, and validate the table with the appropriate business owners.
Can you create a decision table in Excel?
Yes. Excel can be used to document decision conditions, rule rows, outcomes, ownership, and approval status. Executing the table in a rules engine may require additional platform-specific formatting.
What is an example of a decision table?
A purchasing approval table can use purchase amount and urgency as inputs to determine whether supervisor, department manager, finance director, or emergency-procedure routing applies.
What is the difference between a decision table and a decision tree?
A decision table organizes condition combinations into rows and columns. A decision tree represents decisions through branching paths. Both can express decision logic, but their presentation and strengths differ.
What are the main components of a decision table?
The main components are rule identifiers, conditions, condition values, and corresponding actions or outcomes. More formal implementations may also define inputs, outputs, annotations, and evaluation policies.
What is a business rules decision table?
A business rules decision table represents related business constraints and decision criteria in a structured form. It helps stakeholders understand which outcomes apply under particular conditions.
What is the difference between a decision table and a test case?
A decision table describes the rules governing a decision. A test case provides specific inputs and expected results to verify that the decision logic behaves correctly.
What is a decision table hit policy?
A hit policy defines how a formal decision table handles situations where multiple rules match the same inputs. Examples include Unique, Any, First, and Collect.
How do you check whether a decision table is complete?
Identify the valid input combinations and verify that every combination requiring a result is covered. Also check whether overlapping rules produce conflicting outcomes under the chosen evaluation policy.
Are decision tables useful for AI automation?
Yes. Decision tables can represent explicit business logic that an authorized decision service evaluates. AI applications may call that service, but the rules still require appropriate validation, access controls, and monitoring.
Do decision tables replace business rules analysis?
No. Decision tables help represent analyzed rules. They do not independently determine which policy is authoritative, define missing terminology, or resolve unresolved business questions.
Conclusion
A decision table template provides a practical way to organize business rules into conditions and outcomes that stakeholders can understand, review, and maintain.
Whether you are documenting purchasing approvals, customer discounts, eligibility checks, or request routing, the most important steps are the same:
Define the decision clearly, identify authoritative business rules, represent relevant condition combinations, verify coverage, and validate the outcomes.
The reusable template and worked examples in this guide provide a starting point for doing that work.
The purpose of a decision table is not simply to organize information. It is to make business decisions explicit enough to be understood, challenged, validated, and applied consistently.
For organizations preparing business knowledge for decision modeling or automation, RonBot offers a starting point for exploring AI-assisted business rules analysis.