This is the second article (see the first here) 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 on the Boolean ‘OR’ operator in rule conditions.

It is a widely known rule of thumb that business rules should be atomic and that they should eschew the use of the Boolean OR operator between conditions. Only rules with single conditions, or multiple conditions that are ANDed together are recommended. In this article we consider the case for this prohibition, before explaining why, in some cases, an OR is not only acceptable, but advised…


Several pivotal rule texts, for example Ross’s Principles of the Business Rule Approach (p245) [3], the excellent The Decision Model by von Halle and Goldberg (Structural Principle 6, p192) [2] and some, commercially available, business rule training materials suggest that rule authors should avoid rule conditions that use the Boolean operator ‘OR.’

Amongst the reasons usually quoted for this advice are:

  • Ambiguity: if rule conditions are permitted to include mixed use of AND and OR operators, at the same level, this can cause confusion and multiple meanings.

Consider the Rule:

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
then defer shipping until payment clears

this text has several interpretations:

  • Either we defer shipping only when we receive a high value order from a low rated customer and, regardless of value, when it’s the customer’s first order.
  • Alternately it might indicate that, given a high value order, we should defer shipment if this is the customer’s first order or they have a poor credit rating.

In the context of business rules, any ambiguity is very undesirable

  • Sequence: we can correct the ambiguity above by added parenthesis to the rule, hence:

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)
then defer shipping until payment clears

However this use of brackets imposes an execution order on the rules, which detracts from their declarative nature. From the design perspective this might well compromise their execution efficiency. From a business user’s perspective it might well make the rule harder to understand: parenthesis are not a natural concept to some SMEs.

  • Atomicity: any rule that features an OR operator can be split into two separate rules without loss of meaning. For example, consider the corrected rule above, this can be split into two (clearer) rules:

if the order’s value exceeds $2000 and the customer’s credit rating is not AAA
then defer shipping until payment clears


if the order’s value exceeds $2000 and this order is the customer’s first order
then defer shipping until payment clears

Therefore, the single expression of the rule violates first normal form. In the Decision Model this constitutes a serious breach of structural integrity.

For rule capture and analysis, the Decision Model’s strict structure has many advantages. However, for the depiction of rules to the business user and their long term governance and maintenance, the prohibition against ‘OR’ has several drawbacks:

  • It is rather draconian: it could be argued that depriving business rule authors of the use of ‘OR’ is to remove a significant part of their vocabulary and expressive power. If, as is likely, the business users final it natural to express rules in full business English, it is likely to be a nuisance to have such (apparently) arbitrary restrictions imposed on them. Consider also that testing for set membership (if the credit rating of a customer is one of {AAA, AA, A}) can also be considered an implicit OR and this too would be denied under such a restriction.
  • It increases the number of rules: in the example above, the number of rules doubled as a consequence of making them atomic. It could be argued that this slight enhancement of clarity and technical purity has come at the heavy cost of increasing the rule set size and thus their maintenance burden. The size of a rule set has consequences for how easy rules are to find, maintain and refactor.
  • It decreases the locality of rules: whereas initially we had only one rule that deferred shipping, we now have two. To comprehend fully the shipping policy we have to be aware of and understand twice as many rules. This makes it harder to ‘see the big picture’ and keep these rules consistent.

It is clear from the first points that the overuse of OR should be avoided, lest our rules become a labyrinthine twist of deeply nested clauses. But a strict ‘OR’ prohibition is unnecessary providing we follow some simple rules:

  • Keep it simple: build your conditions to use no more than two levels of nested ANDs and ORs (the example uses two). Occasionally using three levels is acceptable, under exceptional circumstances, when it is warranted by the business logic and providing it does not obfuscate. If you need to use more: factorize the rules as we have shown above.
  • Disambiguate: always make your intent clear. Avoid excessive use of braces, instead consider bullet lists. As an example of the latter, consider the following rule with a three deep nesting structure):

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 or the customer has changed address in the last one year or the order does not require a signature))
or  the customer has a prior payment default
then defer shipping until payment clears

Consider instead the equivalent rule, using a bullet list representation: Pasted Graphic 6

  • Consider Alternative representations: in the case of the example above, be aware that there are other means of representing such logic that are inherently clearer. Consider the decision table approach illustrated in Figure 1 or the tree approach illustrated in Figure 2. Both of which are clearer than the text.

Pasted Graphic 4
Figure 1 Rule Depicted as Decision Table
Pasted Graphic 1
Figure 2 Rule Depicted as Decision Tree

We prefer the decision tree representation here – but the decision table is more compact and more scalable.

  • Consider Factoring Conditions. It is also possible to represent common combinations of ANDed and ORed conditions as a simple, derived fact, defined by another rule. This is especially useful if combination is frequently reused. For example, in the rule above, the (separate) definition of the rule to determine if an order is ‘risky’ thus:
    Pasted Graphic 7
    would help to remove the complexity of the main rule, by splitting into into two, at the cost of some locality. However, if the concept of ‘risky order’ is ubiquitous, this separation is doubly beneficial as it promotes consistency. ‘Risky order’ could be used as a condition in many other rules, improving the clarity of each by simplifying them.


Any strict ban on use of the ‘OR’ construct is clearly an overreaction. One which, if imposed absolutely, will diminish the pragmatic value of rules

Instead, the use of OR should be permitted within careful guidelines. If using nested ORs and ANDs, ensure you select the most appropriate representation and limit nesting to no more than three levels. Where reuse of a condition pattern is detected between rules, factor the definition of conditions (using a definitional rule) in order to simplify the rules and maximize their reuse potential. Consider the use of The Decision Model to ease this factoring.

Some BRMS allow lexical complexity guidelines, such as these, to be automatically checked. A governance process for rules, in which these and other quality checks are applied and failures reported, is always strongly recommended for rule sets of non-trivial size.


  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.
  3. Principles of the Business Rule Approach, Ronald G Ross, Addison-Wesley IT Series, ISBN 0-201-78893-4, 2003.
Useful? Please share: