DMN decision tables: formalizing business rules without programmers

Decision Model and Notation (DMN) is a relatively young OMG standard (2015) that often stays in the shadow of its “big brother” BPMN. In automation projects, however, DMN turns out to be no less important a tool than BPMN.

Why a separate standard for rules

For a long time business logic was embedded directly into BPMN diagrams through XOR gateways with numerous branches. When there were more than a dozen rules, the diagrams turned into an unreadable jungle. On top of that, changing the rules required changing the process diagram, which led to unnecessary coupling.

DMN solves this by separating decision logic from process logic. A BPMN Business Rule Task references a DMN model, which can change independently.

Two levels of DMN

DMN has two levels of abstraction:

DRD (Decision Requirements Diagram)

A DRD is a graph of dependencies between decisions. Each node of the graph is a separate decision that requires certain input data. Decisions can depend on one another, forming a hierarchy.

For example, in the task of assessing a loan application:

• “Approve the loan” depends on “Scoring” and “Income check”
• “Scoring” depends on “Repayment history” and “Credit load”
• “Income check” depends on “Employment type” and “Confirmed income”

Decision tables

Decision tables implement the concrete decision logic. Each row of the table is a rule. Each column on the left is an input variable, on the right the output value.

An example table for the “Scoring” decision:

Repayment history	Credit load	Age	Score
Excellent	< 30%	> 25	95
Excellent	< 30%	≤ 25	80
Good	< 50%	> 25	75
Good	< 50%	≤ 25	60
Average	< 70%	-	45
Poor	-	-	20

Hit policies

DMN defines several policies for how to handle situations where more than one row of the table matches:

• Unique (U) — exactly one row must fire, otherwise an error
• Any (A) — several rows may fire, but all must give the same result
• First (F) — the first matching row fires (order matters)
• Priority (P) — the rule with the highest priority applies
• Collect (C) — a list of all results is gathered

The choice of policy substantially affects the semantics. Most practitioners recommend using Unique where possible — it gives maximum predictability.

FEEL — the expression language

DMN includes a purpose-built expression language, FEEL (Friendly Enough Expression Language). Its job is to let analysts write complex rules in a form that is human-readable yet strictly formalized for the computer.

Examples of FEEL expressions:

[100..500]        // the range 100–500 inclusive
> 18              // greater than 18
not("London")     // not equal to "London"
in ("UK", "IE")   // one of the values
date("2025-01-15")

FEEL supports arithmetic, logic, and working with strings, dates, lists and contexts. It is not a general-purpose programming language but a specialized declarative language for business rules.

Where DMN is used

Typical scenarios:

• Credit scoring — calculating a score and the approval decision
• Insurance premiums — pricing a policy from the client’s parameters
• Request routing — selecting an operator to handle a request
• Product configuration — the allowed combinations of parameters
• Discount calculation — applying promotions and loyalty programs

Platforms

DMN is supported in the main BPM engines: Camunda DMN, IBM ODM, Drools, Trisotech, Signavio. Some of them provide visual decision editors for business analysts.

Limitations

• DMN is not suited to machine learning or fuzzy logic
• Complex multidimensional rules become unwieldy in table form
• The standard is less well known than BPMN, which makes finding specialists harder

Conclusion

DMN is a powerful, underused tool. Adopting DMN alongside BPMN lets you substantially simplify process models and give business analysts direct control over decision logic without turning to developers.