Decisions come in many forms. High-level, long-term, strategic business decisions are important in business. But they are hard to model and hard to automate. Instead, we are dealing with the so-called operational daily decisions that are present in everyday business operations and processes. Decisions about pricing, eligibility, discounts, ratings, offers. Each decision by itself doesn’t necessarily represent high value for the company, but there are so many of them, so the total impact is enormous. Some organizations, like 24 Hours Fitness, report of over 90 million evaluated decisions every single day. Understanding these decisions becomes a critical skill in automation.

It's no surprise that decision management and modeling serves multiple purposes. In automation and digital transformation contexts, we use them for analysis and optimization of decisions, requirements analysis, and software testing.

The best way to describe decision logic is to use decision tables. The use of decision tables is also advocated in the DMN-standard (Decision Model & Notation). With a decision table, you can model and structure complicated decision logic and complex business rules. It might be easy to overlook a combination of rules or conditions manually. But a structured decision table gives you an accessible overview of all the rules to avoid these kinds of mistakes.

A decision table is a tabular format to structure business rules. Its form was standardized by DMN. Do you know the essential elements of a Decision Table? No? Don’t worry – we’ve got you covered with our new poster: “The Decision Table Anatomy”.

Meanwhile, I hope you all know what a decision table is. For those who skipped the introduction, let’s define it once more. In a decision table, a collection of rules is represented that will determine the ouput of a decision based on certain inputs.

Typical operational rules look like this: input – value expression – logical operator – input - value expression => output. But if we have tens of rules, they become much harder to make them consistent.

A decision table structures the rules as a table.

The rows in the table typically represent the rules that are involved. The columns represent the inputs and outputs of the decision, also called information items or value expressions, when a value is assigned. The header row contains the name of the decision, as well as the names of the information items and the possible values they can hold. Underneath this header, you’ll find the value expressions that make up a rule.

For the more critical readers here: yes, even for potentially overlapping rules this decision table offers a solution. A hit policy. In the left corner of the table will tell you how to interpret possible overlapping rules.

Now you know why you should be creating decision tables and how you have to do that, I’m left wondering… what are you still doing here? Let’s get to it!