Decision Model and Notation, or DMN, is a novel way to model business decisions. Every organization must distinguish between business decisions and business processes, not only that, they have to have a decision management practice in place.

DMN allows the capture and modeling of business decisions in a way that is easy to understand for business people and subject matter experts. It is a combination of the following models:

  1. Decision Requirements Diagram – DRD
  2. Decision Table
  3. Boxed Expressions
  4. Friendly Enough Expression Language (FEEL)

There is a big difference between modeling business decisions and business process and I believe DMN deliver this principal very clearly.
– Arash, FlexRule Founder

At a very high level, the movement of standardizing modeling and executing business decisions and rules provide a significant opportunity to all organizations for several reasons.

  • Interoperability: Like all industry standards, interoperability is at the core of the benefits of supporting Decision Model and Notation (DMN). For instance, in a Business Process Management solution that has the ability to define rules but not complex decisions and business rules, you can now simply drag and drop a DMN package, and it executes the DMN model that you built in a Decision Management Suite that supports the full extent of DMN to create very complex decisions and business rules.
  • Migration: As the users and companies want to adopt decisioning technologies, it is easier to migrate from older systems if they support DMN. Even if the old one does not support DMN, the migration process becomes easier by capturing decisions and rules in DMN and bringing them to a new platform.
  • Finding talent and training staff: Standardization makes finding talent easier, so talents who know the standard and have worked with it can be hired. Training internal staff also becomes easier because there are loads of articles, tutorials, etc., about the standard. Although the implementation of them still depends on the vendor's capabilities, it is better than nothing.

Let's go ahead and understand the standard in more detail…

Conformance Level

In DMN, there are three levels of conformance, meaning the vendor platform that claims they are DMN compatible is in one of these levels; note that compliance at one level must also be compliant with any preceding levels:

  • Level 1: Visualization of Decision Requirements Diagram (DRD) and Decision Table for #businessrules. Imagine a standard way of illustrating (or printing) decisions and rules.
  • Level 2: Partial section of fully executable FEEL, decisions, and rules.
  • Level 3: Full set of Boxed Expressions and support for all FEEL expressions.

The most valuable conformance level is 3, where you can not only model but also execute business decisions and rules. As a side benefit, this avoids the venrod's locked-in issue.

Decision Requirement Diagram (DRD)

This is a graphical model that allows modeling dependencies between input data, decision, business knowledge and knowledge sources.

Decision Model and Notation - DRD sample

In DRD, the arrows show the dependencies between different nodes in the model. To put it in a simple way, you can read it as if the output result of some nodes will be passed as the input of the other nodes.

In the table below, all of the elements on a DRD model are illustrated:

DecisionDecision Model and Notation - Dmn decisionThe act of determining an output from a number of inputs, using decision logic, which may reference one or more business knowledge models.
BusinessKnowledge ModelDecision Model and Notation - Dmn business knowledge modelA function encapsulating business knowledge in the form of business rules, decision table or analytic model. Some of the tools may not support this element. In such cases, the decision logic is directly linked to the Decision rather than the business knowledge model.
KnowledgeSourceDecision Model and Notation - Dmn knowledge sourceThe authority for a business knowledge model or decision.
Input DataDecision Model and Notation - Dmn input dataInformation used as an input by one or more decisions. It also denotes the parameters of a Business Knowledge Model.
Information RequirementDmn information requiredInformation – input data or decision output – required for a decision.
Knowledge RequirementDmn knowledge requiredThe invocation of a business knowledge model.
Authority RequirementDmn authority requiredShowing the knowledge source of an element or the dependency of a knowledge source on input data.

Decision Table

In Decision Model and Notation, the Decision Table is a tabular form that models rules based on conditions and actions which are also called inputs and outputs. Decision Table is the default type of modeling business rules in DMN. But if your tools support other ways to model business rules then you can freely use them alongside decision table.

Decision Model and Notation - decision table

Learn more – How to use Decision Table in modeling business rules.

Boxed Expressions

Decision Model and Notation (DMN) is a simple two column table and an effective way to model business formulas, calculations, values and expressions. Then you can share these across multiple decisions and logic.

Boxed expressions simply allows modeling: constant, values, invocation, formulas, etc. Boxed expressions allows you to put together building blocks of logic (i.e. decision table, natural language, flow, etc.) and enables you to reuse these over and over again.

Friendly Enough Expression Language – FEEL

In Decision Model and Notation, FEEL is an expression language for business people. FEEL defines a syntax for expressing conditions, actions and formulae. FEEL is like using Excel formulas in that it allows you formulate your thinking about a domain in a context. FEEL is designed for ease of use by business people and subject matter experts.

Book a Custom Demo

First or last name is too short


There are many benefits to using Decision Model and Notation over the traditional business rules approach. In the business rules approach, very soon you start thinking about the logical implementation of the actual rules. But the DMN approach provides a higher-level abstracted layer that allows you to see the big picture first rather than diving deep into implementation and potentially losing the context and oversight of the solution.

This change of approach:

  1. Allows scaling of business rules in a more manageable, reusable visual approach across applications and processes.
  2. Allows better communication between the business, domain experts and IT by enabling a more productive involvement of business people and subject matter experts.
  3. Allows clearly defined decision boundaries and exposes the decision as a service with a click!

If your tool supports simulation and execution, error checking at design time and runtime with debugging capability, then you will not overlook anything by using a business rules approach, but you will also have a better way to reuse and scale your business rules in a systematic way.

Last updated June 6th, 2024 at 03:09 pm Published June 11th, 2016 at 12:16 pm