Decision Table Editor

What Is a Decision Table?

A decision table is a structured representation of business logic that maps combinations of input conditions to specific output values. Instead of writing nested if-else statements or complex switch cases, you lay out every relevant condition as a column, every possible output as another column, and every rule as a row. The result is a grid that any stakeholder — developer, business analyst, or product manager — can read and verify at a glance.

Decision tables have a long history in software engineering. IBM introduced them in the 1960s as a way to document business rules independently of any particular programming language. The idea was simple and powerful: separate the logic of a decision from its implementation. Decades later, the Object Management Group (OMG) formalised this concept in the Decision Model and Notation (DMN) standard, which defines a precise specification for how decision tables should be structured, annotated, and evaluated. DMN decision tables are now part of enterprise automation platforms, business process management suites, and rules engines worldwide.

The right time to use a decision table is when you have a rule with multiple input conditions that produce categorically different outputs. Pricing tiers, loan eligibility checks, support ticket routing, discount calculations, compliance flag assignments — these are all naturally tabular. When the number of conditions and outputs grows beyond two or three, a table is almost always clearer than the equivalent code.

How to Build a Decision Table Online

Building a decision table is a structured process, and the Koodisi Decision Table Editor is designed to guide you through each step without requiring any coding knowledge.

Step 1: Define your input conditions. Start by identifying the variables that determine the outcome of your rule. Each input condition becomes a column header in your table. For example, a shipping cost rule might have three input conditions: Customer Type (Standard / Premium), Order Weight (in kg), and Destination Region (Domestic / International). Be specific — the more precisely you define the condition, the easier the table is to evaluate.

Step 2: Define your output columns. What should the rule produce? An output might be a single value — a price, a status code, an approval decision — or multiple values if the rule produces a compound result. In the shipping example, outputs might be Shipping Cost and Estimated Days. Each output becomes its own column in the table.

Step 3: Fill in the rule rows. Each row in the body of the table is one rule. For a given combination of input values, the row specifies the corresponding output values. A row might read: Customer Type = Premium, Order Weight <= 5kg, Destination = Domestic → Shipping Cost = $0, Estimated Days = 1. Conditions that do not apply to a particular rule can be left blank (or set to "any"), meaning that condition is not evaluated for that row.

Step 4: Set the hit policy. The hit policy determines what happens when more than one row matches the input data. This is one of the most important settings in a DMN decision table — choose the wrong one and your table may produce incorrect or ambiguous results. The most common policies are described in detail below.

Step 5: Test with sample data. Enter representative input values and dry-run the table. The editor evaluates each row in order and shows you which rows matched and what output was produced. Verify that edge cases — the heaviest order, the least privileged customer, the most restrictive region — produce the expected results.

Decision Tables vs. If-Else Logic: Why Tables Win

Every developer has written deeply nested conditional logic at some point. It starts simply enough — an if for one condition, an else for another — and then requirements arrive. New customer types, additional price tiers, regional exceptions. The code grows into something that requires significant mental load to follow, and testing it exhaustively becomes a manual process of constructing edge-case inputs and checking outputs one by one.

Decision tables address this directly. The same logic that might span forty lines of nested conditionals can often be expressed in a ten-row table that fits on a single screen. The advantages are concrete:

• Readability for non-technical stakeholders. A business analyst can read a decision table and immediately verify whether the rules match the business specification. The same analyst cannot meaningfully review a nested conditional in code. This closes the gap between the people who define business rules and the people who implement them.
• Completeness checking. A well-formed decision table makes it easy to ask: "have I covered every combination of inputs?" Gaps — input combinations that no row matches — are visible as blank spots in the table. In code, gaps silently fall through to a default case that may or may not be correct.
• Maintainability. Adding a new rule is adding a row. Changing an output value is editing a cell. In code, the equivalent change requires understanding the existing control flow before making the modification — and risks introducing a regression in a branch you did not intend to touch.
• Testability. Each row in a decision table is an independently testable rule. You can write one test case per row and achieve full rule coverage with a small, structured test suite.

None of this means decision tables replace all conditional logic. Simple two-branch conditions, logic that involves iteration or recursion, and rules that depend on complex computed values are still better expressed in code. Decision tables shine specifically when the logic is tabular by nature — many combinations of discrete inputs producing discrete outputs.

DMN Decision Tables in Business Automation

The Decision Model and Notation (DMN) standard, published by the Object Management Group in 2015, brought rigour and portability to decision table modelling. Before DMN, every rules engine and BPM platform had its own proprietary format for defining decision tables. Migrating between platforms meant re-entering rules by hand. DMN standardised the structure so that a decision table defined in one platform could, in principle, be exported and imported into another.

DMN is often mentioned alongside BPMN (Business Process Model and Notation), the standard for modelling business processes as flow diagrams. The two standards are complementary: BPMN describes the flow of a process (what happens in what order), while DMN describes the decisions within that process (given these inputs, what is the outcome?). A BPMN process diagram might include a "Determine Eligibility" task that delegates its logic to a DMN decision table. Together they provide a complete, human-readable specification for automated business processes.

In enterprise automation platforms — Camunda, Flowable, IBM ODM, Drools, and others — DMN decision tables are first-class citizens. Business rules teams can define and update decision tables without deploying new code, which dramatically shortens the cycle time for rule changes. A pricing update that used to require a developer, a code review, and a deployment can become a table edit and a publish.

Koodisi's Decision Table Editor is built with DMN compatibility in mind. Tables defined in the editor follow DMN semantics for hit policies, condition expressions, and output types, so rules you model here translate directly to the decision table constructs in enterprise automation platforms.

Decision Table Use Cases for Enterprise Workflows

Decision tables appear throughout enterprise operations wherever discrete inputs determine discrete outputs. Here are the most common and impactful use cases.

Pricing and discount rules. Pricing logic is almost always tabular. Customer tier, product category, order quantity, contract type, and promotional period each contribute to a final price or discount percentage. A decision table makes every pricing rule explicit, reviewable by finance and sales teams, and independently testable. When a promotion ends or a new tier is introduced, the change is a row edit — not a code deployment.

Loan and credit eligibility. Financial services organisations evaluate loan applications against a matrix of credit score ranges, income thresholds, debt-to-income ratios, and employment types. Each combination maps to an approval status, a maximum loan amount, and an interest rate tier. Decision tables make this logic auditable — a requirement in regulated industries — and easy to update when underwriting criteria change.

Support ticket routing. Incoming support requests arrive with a product area, severity level, customer tier, and reported issue type. A decision table maps these inputs to the appropriate support queue, escalation path, and SLA target. When you add a new product line or change escalation thresholds, you add or modify rows rather than updating routing code spread across multiple services.

Compliance and risk flag assignment. Regulatory compliance often requires evaluating transactions against a set of rules and flagging those that meet certain criteria. Transaction amount, counterparty jurisdiction, product type, and account age might each trigger or suppress a compliance flag. A decision table makes the flagging logic transparent to compliance officers, who can review and sign off on the table directly.

Order fulfilment and inventory routing. When an order comes in, multiple factors determine how it should be fulfilled: stock availability at each warehouse, shipping zone, order priority, and carrier preference. A decision table encodes the routing logic so that operations teams can understand and modify it without needing to read the fulfilment service's source code.

Testing Business Rules with Decision Tables

One of the most underappreciated advantages of decision tables is how naturally they support systematic testing. Every row is a rule, and every rule has a clearly defined set of inputs that should trigger it and an expected output. This structure maps directly to test cases.

Happy-path testing. For each row in your table, construct an input that matches exactly the conditions in that row and verify the output matches the expected value. This gives you one-to-one coverage: every rule has at least one test.

Edge case testing. Conditions that involve ranges are particularly important to test at their boundaries. If a condition is Order Amount >= 100, test with values of 99, 100, and 101. If a condition is Customer Type = Premium, test with each non-Premium type to confirm they do not accidentally match. Boundary conditions are where decision tables most commonly contain errors.

Gap testing. A well-designed decision table should have a rule that matches every possible combination of inputs. If it does not, an unmatched input will either throw an error or silently return no output. Before deploying a decision table to production, test inputs that do not match any rule and verify that the table handles them appropriately — either by returning a defined default or by raising an explicit error.

Regression testing. When you add or modify a row, re-run the full test suite against the updated table. Because each row is independently testable, adding a rule for a new case should not affect the outcomes of existing rules — unless your new row inadvertently changes the hit policy behaviour for a pre-existing input combination. Catching this automatically with a regression suite is far better than discovering it in production.

The Koodisi Decision Table Editor's dry-run feature supports this testing workflow directly. Enter sample inputs, run the evaluation, and inspect which rows matched and what output was produced. You can iterate on the table structure and immediately verify the updated logic without leaving the browser.

Decision Tables in Integration Platforms

Decision tables become especially powerful when embedded in integration workflows. An integration that moves data between systems often needs to apply transformation logic: "if the incoming order has this status, route it to this queue; if it has that status, route it to a different one." This logic is decision-table logic, and it benefits from all the readability and maintainability advantages described above.

In Koodisi's workflow automation platform, decision tables function as a named, reusable step within an integration flow. Rather than embedding conditional logic directly in a mapping expression — where it is invisible to non-developers and difficult to maintain — you define the logic as a decision table, name it, and invoke it by name from any flow that needs it. The same pricing table used in the order fulfilment flow can be referenced in the invoice generation flow and the customer notification flow. When the pricing rules change, you update one table and all three flows reflect the change immediately.

This approach also separates concerns in a way that makes teams more effective. Integration developers focus on the plumbing — connecting systems, mapping fields, handling errors. Business analysts focus on the rules — defining conditions, setting outputs, testing edge cases. Decision tables are the interface between these two roles. They are formal enough to be executed by the platform, but readable enough to be owned and maintained by the people who understand the business logic.

Koodisi's Decision Table Editor is currently in development. When it launches, it will integrate directly with Koodisi's workflow automation platform, allowing you to define a table in the browser, test it with live data, and deploy it as a step in any integration flow — all without writing code.

Frequently Asked Questions

What is DMN and do I need to know it to use a decision table?

DMN stands for Decision Model and Notation — a standard published by the Object Management Group (OMG) for representing decision logic in a structured, portable format. You do not need to know the DMN specification in detail to use a decision table editor. The concepts — conditions, outputs, hit policies, rules — are intuitive. The DMN standard is what ensures that tables you build follow a well-defined semantics and can interoperate with other DMN-compatible tools and platforms.

What are hit policies and which one should I use?

A hit policy determines what happens when the input data matches more than one row in the table. The most commonly used policies are:

• Unique (U): Exactly one row should match for any input. If more than one row matches, it is a modelling error. Use this when rules are designed to be mutually exclusive.
• First (F): Rows are evaluated in order; the first matching row wins and evaluation stops. Use this when rules have a natural priority order.
• Any (A): Multiple rows may match, but they must all produce the same output. Use this when the same output can be derived from multiple input paths.
• Collect (C): All matching rows are returned, and their outputs can be aggregated (summed, counted, listed). Use this for rules that can produce multiple results simultaneously.

For most business rules, Unique or First is the right starting point. Unique is cleaner — it forces you to define non-overlapping rules — but First is more forgiving when rules naturally overlap and priority order is the intended tie-breaker.

When should I use a decision table instead of writing code?

Use a decision table when your logic is tabular by nature: multiple input conditions, discrete output values, and the same structural pattern repeated across many rules. If you find yourself writing more than three levels of nested conditionals, or if non-developers need to review or maintain the logic, a decision table is almost certainly the better approach. Decision tables are less suitable for logic that involves iteration, complex computations, or stateful decisions that depend on a sequence of past events.

How many rows can a decision table have?

There is no hard limit on rows. In practice, decision tables with more than 50–100 rows often benefit from being split into sub-tables that each handle a subset of the logic. Very large tables can be difficult to review and maintain, and splitting them usually reflects a natural decomposition in the business logic — a "customer tier" sub-table and a "product category" sub-table, for example, rather than one massive table combining both dimensions. The Koodisi Decision Table Editor will support linking tables so that one table can invoke another, enabling this kind of compositional structure.

What export formats will the Decision Table Editor support?

The editor is designed to export decision tables in DMN XML format, which is the standard interchange format for DMN-compatible platforms including Camunda, Flowable, and others. JSON export for use in custom rule engines is also planned. Importing existing DMN XML files to continue editing them in the browser is on the roadmap as well. When the tool launches, the complete list of supported import and export formats will be documented in the tool itself.