Designing decision tables

Decision table syntax cheat sheet

Exclusivity of condition alternatives

Shown below is an example of a decision table with overlapping condition alternatives:

There is no check available in Blueriq that tells whether a decision table is complete or whether ranges within a decision table overlap. The overlapping conditions shown above do not result in errors. Someone who is younger than 10 years old will receive a discount, since the first condition (Person.Age<=21) is true for this person. Overlapping conditions result in unclear and unpredictable behaviour. Because of the fact that a decision table is evaluated from left to right, for a person under the age of 10, the first condition alternative (and only the first alternative) will be applicable.

An alternative example which makes use of the fact that it is evaluated from left to right is: 

Shown below is the correct decision table that makes sure that someone who is younger than 10 years old will not receive a discount.

Completeness of condition alternatives

Gaps in ranges within decision tables are not detected by Blueriq and do not result in validation errors however the value can not be determined by using the decision table.

Shown below is a decision table that is not complete:

Lack of completeness in a condition is not always clear to see very quickly. In the table shown here, people who are exactly 21 years of age do not fit in any category. It may take some time to figure this out, if found out at all.

Someone who is 21 will have the default value for Person.Category (if declared) as their category. If such a default value was not declared, category remains unknown until the person turns 22. The table as shown above is not wrong, but it would be much easier to read if it was complete.

Shown below is an example of a decision table that is incomplete, but it is much clearer that this is the case:

In the example above, it is really obvious that the decision table is not complete regarding gender. For females, no age distinction is applicable to determine the discount for some fictitious product: they all receive 7% discount. Arguably, a default value suits very well. On the other hand, the decision table as shown below is also very readable. As mentioned before, this is subject to debate.

Size of a decision table

With multiple condition alternatives, a decision table can become very large in size. Decision tables that are too large in size become unclear and incomprehensible. In general a table should have a maximum of 12 columns / action values. When the number of columns exceeds this number, it is recommended to split up the table. 

Splitting up a decision table can be done by using sub-decisions. These can be created by adding an additional (conceptual) attribute or using of reusable expressions.

A possible alternative using sub-decisions is displayed below.  

Order in a decision table: Condition subjects

When designing a decision table, it is worth considering in which order the different conditions (rows) are declared. To illustrate this, see the two semantically equivalent decision tables below.

One might argue that - because of the fact that the decision tables are semantically equivalent - it does not matter if you model the first or second table. However, there are two differences that are worth addressing and should be taken into account when designing decision tables:

1. If the company that uses this decision views its customers mostly by their gender, the first table is preferred. The company tends to think male versus female, so it makes sense that in decision tables male-female is the first row. If the company that uses these decision tables views their customers in age categories, the second decision table is preferred.
2. In general the transparency or understandability of a decision table improves when the conditions are declared with the number of condition alternatives increasing from top to bottom. So even if the first argument of gender and age categories does not apply, there is a theoretical preference for the first table. This is illustrated below.

Order in a decision table: Condition alternatives

The order of condition alternatives is almost always irrelevant, even when using ELSE ( [] ). However it is recommended to sort the condition alternatives in a logical order and not use an ELSE in a range. This improves transparancy and readability. 

In the example shown above, it is of no concern for the business engineer that the decision table is evaluated from left to right by the rule engine. In this particular domain, we know that gender is either Male or Female and neither both, nor unknown, so the order in which the columns appear is absolutely irrelevant. In circumstances like this, it is merely a matter of taste what the order of the columns is. Most likely - and advised - the most discriminating condition alternative is most important and therefore placed left for purposes of understandability.

Now, study the example below and ask yourself this question: "Will someone with the age of 15 receive a discount?"

Many people might believe that the answer is No (a person aged 15 will not get a discount), since reading from left to right means that the first condition to be evaluated is ELSE. However:

So the answer is Yes, someone with the age of 15 will receive a discount.

Same question again, different decision table: "Will someone with the age of 15 receive a discount?"

Reading from left to right suggests No, this person will not receive a discount since the second condition (Else) applies after concluding that the condition Person.Age <= 10 does not apply.
However, keeping in mind the statement about Else as mentioned before suggests that a discount is applied, since the third condition alternative (Person.Age >= 14) applies. The correct answer is the latter, a person aged 15 will receive a discount!

In the first sentence of this chapter the phrase "almost always irrelevant" is used, which means that there must be a situation where the order of condition alternatives actually is relevant. This is the case when using multivalued attributes. To find more about this, see Multivalued attributes in decision tables.

Attribute versus expression in a condition subject

It is recommended to use attributes as a condition subject and their value as condition alternatives. This improves transparancy, readability and performance. See the two decision tables below.

The bottom decision table uses an expression instead of an attribute. This pattern is bad practise.

Focus on results in relation to the requirements

A safe and fairly easy way to approach the design of a decision table is by creating an action value for each possible combination of attribute values. However, this will result in a combinatoric explosion of condition alternatives and very large decision tables. When all action values differ, this is the correct approach. Most likely, they will not. In that case, the focus should be on the action values instead of the combination of attribute values. To illustrate this, see the small example below.

Because of the fact that there are two genders and three age categories, it might not be a big surprise that there are six action values. However, a closer look at these values - with the focus on the DiscountPercentage of 10 - reveals two possible design alternatives:

1. All males under 21 receive a 10% discount. If the company that uses this decision talks about "males under 21", this is a good approach. It means something to them.

2. All applicants under 18 receive a 10% discount, no matter the gender. If the company that uses this decision talks about "anyone under 18", this is a good approach.

Extreme focus on results

It is not a best practice that each decision tables must always contain exactly one result attribute for each possible value. It could be a good starting point in design, but it should not be the ultimate goal to establish one result attribute for each possible value.To illustrate this, the example above has been redesigned to match the before named strategy. In the example above, there are only four discounts: 10%, 20%, 25% and 30%. The decision table holding a result attribute for each value will look like the one below, which in this particular case is not as understandable and transparent as the two (green) decision tables above:

There is an exception; when the condition identifies a distinct class of customers who always receive a 10% discount, this class of customers should be part of the domain model and is a third discriminating factor, alongside with gender and age.

Expressions in the Condition column of a decision table

It is possible to use an expression in the left column of a decision table. For instance a count on instances that results in a number that is evaluated.

This possibility in Blueriq offers the business engineer extensive options to create a model. The problem is that especially large expressions are not very transparent for business users. There are two options to avoid large expressions in decision tables.

Option 1: Use a support attribute

Option 2: Use a reusable expression

Too compact and too elaborate decision tables

Let's assume that for a particular benefit

1. your income may not be too high,
2. your rent must be within boundaries,
3. your savings may not be too high.

Only when you meet all three requirements, you are granted this benefit. A faulty decision table is shown below:

The decision table shown above will decide that someone is eligible for a benefit whenever he or she fulfills all three requirements. It will also conclude that someone is not eligible for this benefit whenever he or she fulfills none of the requirements. However, the table is not complete. What will happen when someone only fulfills some of the requirements?

So, in this light it might be tempting to elaborately describe all possible scenarios:

The decision table shown above is correct and will work properly. However, it could be modeled using way less result attribute values. To understand this, imagine that the first requirement about income is false. Does rent matter? No, it doesn't. The same could be told for savings.... See the compact decision table below.

Decision tables with requirements that must all be met

Shown below is a correct decision table that decides the eligibility for a particular benefit. Your income may not be too high, your rent must be within boundaries and your savings may not be too high. Only when you meet all three requirements, you are granted this benefit.

One might argue in cases such as these, where only the most left result attribute is true and the rest is false, a much shorter implementation is possible. See the exact same implementation of the benefit below, where the default value of the eligibility is set to false and a shorter decision table will only overwrite the eligibility when all requirements are met. 

However it is not recommend to use an implementation like this since it is incomplete and not transparant. Choices are made implicitly rather than explicitly. It is recommended to use a complete decision table to improve readability.