This is the first of an occasional series, “Breaking the Rules”, in which we look at the sacred rules governing business rule design and examine some exceptional circumstances under which they can, and should, be broken. In this article we investigate the prohibition of multiple actions (or, more correctly, conclusions) in definitional rules. Should your rules only have one action as some authorities suggest? Or are there occasions when more than one action is allowed?

It is a widely known rule of thumb that definitional business rules, those that reach a conclusion from a set of conditions, should have only one conclusion type and no more. In this article we consider the case for this prohibition, before highlighting reasons why multiple conclusion types in a single rule are not only acceptable in some cases, but strongly advised.


According to Ross, in Business Rule Concepts [1], a definitional (or structural) rule is one that makes a decision, or reaches a conclusion, based on one or more condition fact types. They are so called to distinguish them from behavioural rules which define absolutes of business behaviour (either obligations or prohibitions). Behavioural rules serve to distinguish the difference between correct and incorrect business behaviour, they can be violated directly, whereas definitional rules cannot.

Definitional rules reach a conclusion (by classification or computation) which causes the creation of a new fact instance – they structure knowledge by deriving new facts from existing ones. For example the rule:

An order is high risk if the order’s value exceeds $2000 and (the customer’s credit rating is not AAA or this order is the customer’s first order)

creates a new fact, the order is high risk, if its condition is satisfied. This fact may be used as the basis of conditions in other rules both definitional and behavioural.

The following, decision table rule, Figure 1, with condition rows in orange and conclusion rows in green, reaches two conclusions (the short term credit limit, STCL, offered to a customer and the class of a customer) from the same conditions (the customer’s credit rating, average order value and the number of orders they placed in the last year):
Pasted Graphic 8
Figure 1 Decision Table with Two Conclusions (Unrelated)

Don’t Jump to (More than One) Conclusion

Several pivotal rule texts, for example the excellent The Decision Model by von Halle and Goldberg (Structural Principle 5, p188) [2], commercially available business rule training materials and Ross’s Business Rule Concepts (p89) [1] suggest that rule authors should avoid definitional rules that have more than one conclusion fact type. In other words: decision tables with more than one action column, or English rules with more than one action.

This rule of thumb is well justified by these works. Amongst the reasons usually quoted for this advice are:

  • Atomicity: rules with more than one conclusion fact type can be divided into two or more separate (atomic) rules without losing their original intent (as is the case with the decision table in Figure 1). This is better because it allows the decomposed rules to evolve independently – for example, in future, the rule determining the credit limit might acquire other conditions not needed to calculate customer class;
  • Ambiguity: where a rule has more than one conclusion it is not clear if many conclusions are dependent on the same conditions in parallel (as seems to be the case above), or if some conclusions are dependent on the conditions and the others implicitly dependent on other conclusions. Even if the latter seems true it may be disproved by new rules added later – by having multiple conclusions, the rule author has obfuscated her intent;
  • Single Chain of Inferential Causality: it is easy to determine the ‘chain of inference’ of rules having a single conclusion type, that is, the dependency of each rule on other behavioural rules that define their conditions is clear. However, where a rule is dependent on another with more than one conclusion that dependency is unclear, for the reasons given above.

These reasons alone are sufficient for most rule architects to see a decision table like Figure 2:
Pasted Graphic 9
Figure 2 Decision Table with Two Conclusions (Related)
And want to split it into rules like Figure 3 and Figure 4 which separate the definition of the two conclusions, presumably because the conclusions are unrelated except that they are determined by the same conditions. Alternatively the architect might split them into Figure 3 and Figure 5 which defines the short term credit limit (STCL) and then defines the customer class based on the STCL.

Pasted Graphic 10
Figure 3 Decision Table Defining Customer STCL

Pasted Graphic 11
Figure 4 Decision Table Defining Customer Class

Pasted Graphic 12
Figure 5 Decision Table Defining Customer Class in Terms of STCL

Note that the rules of Figure 2 support either approach to separation, whereas the rules of in Figure 1 would only support the former (because customer class and STCL appear unrelated in this rule). When deciding which approach to use however, you must be driven by the business semantics (ask yourself: can customer class always be derived from the STCL alone?), not the happenstance of the rules already known. Be guided by the expertise of your business SMEs.

Limitations of the Single Conclusion Prohibition

Although insisting on this kind of separation is sound in cases in which a single rule has multiple unrelated conclusions, there are cases where splitting related conclusions into separate rules can cause problems, specifically:

  • It reduces the locality of rules: the division of a single rule, with strongly related conclusions, into different rules means that rule authors now have to comprehend more rules to understand the ‘big picture’ of the policy (or at least that part of it represented by the original joined rule). Psychologists have shown that the greater the extent of this separation of related information, the harder it is for humans to understand the overall meaning. The more rules are need to define a policy, the harder the policy is to understand.
  • It increases the maintenance burden: increasing the number of separate, but inter-dependent, rules increases the likelihood that a user will amend one and forget to make a corresponding amendment to the others – introducing an inconsistency.
  • It cancels the benefit of ‘narrative’: the conclusions of some rules are designed to provide narrative to others. Consider the validation decision table in Figure 6 in which the conditions (again, in green) are clearly correlated. Here, the narrative column serves to both document the decision table (specifically the semantics of ‘claim routing code’) and act as human readable traceability information. Separating the narrative column into a separate rule would reduce its value as a narrative. Unless the same narrative is used in other rules, this separation is counter-productive.

Pasted Graphic 2
Figure 6 Decision Table with Narrative

When to Have Multiple Conclusions

We would contest that rules with multiple conclusions can therefore be justified in two cases:

  • Narrative: where the additional conclusions provide human readable documentation, or justification, for the primary one (see Figure 6) providing that the narrative is unique to this rule. If the same narrative for ‘routing code’ were provided in many other rules, separation would be mandated to avoid repetition (1st normal form) and potential inconsistency. In this case a single, separate rule should define the narrative for routing code values. However, if a ‘routing code’ conclusion existed in many rules with context specific narratives, such a repetition would be acceptable.
  • Conclusions are co-Attributes: if a rule contains multiple conclusions, but each can be considered the primary attributes of a single, new fact (like the attributes of a new object) such that the fact could not be said to be completely defined without all these attributes. For example, consider a bond accounting rule (see Figure 7) that generates a set of postings (debits and credits) to a ledger depending on the accounting event, capacity (of the counterparty), the general accounting principles (IFRS is general, HGB for accounting specific to Germany) and the bank’s position with respect to this bond.

Pasted Graphic 3

Figure 7 Accounting Decision Table

In this example, the direction of the posting (credit versus debit), its amount and the account family to which the credit or debit is posted are all integral to the posting. They are attributes of the posting ‘fact’. It is not meaningful to have a posting without any of these attributes. Therefore it is reasonable to reach all three conclusions in one rule.

Furthermore specifying them in one decision table allows business users to see, in one place, how, for example, the accounting for a coupon settlement (see the last three lines) works. Separation would treble the number of accounting rules and obfuscate their behaviour.


Every rule should have one and only one conclusion fact type, unless some conclusions are a unique narrative of the primary conclusion, or a set of conclusions are all attributes of the same conceptual fact type and separating them would constitute a hazard to rule comprehension, maintenance and integrity.


  1. Business Rule Concepts 3rd Ed., Ronald G Ross, Business Rule Solutions LLC, ISBN 9-941049-07-8, 2009.
  2. The Decision Model, Barbara von Halle and Larry Goldberg, CRC Press, ISBN 978-1-4200-8281-4, 2010.
Useful? Please share: