Decision Model and Notation, or DMN, is a novel way to model business decisions. 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:

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

Decision Requirement Diagram (DRD)

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

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:

Element Notation Description
Decision Dmn decision.png The act of determining an output from a number of inputs, using decision logic which may reference one or more business knowledge models.
BusinessKnowledge Model Dmn business knowledge model.png A 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.
KnowledgeSource The authority for a business knowledge model or decision.
Input Data Dmn input data.png Information used as an input by one or more decisions. It also denotes the parameters of a Business Knowledge Model.
Information Requirement Dmn information required.png Information – input data or decision output – required for a decision.
Knowledge Requirement Dmn knowledge required.png The invocation of a business knowledge model.
Authority Requirement Dmn authority required.png Showing 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

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.
decision model and notation

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

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.


There are 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.

Read More

  1. Import DMN models – XML 1.1
  2. Boxed Expressions – DMN
  3. Decision Model and Notation – DMN
  4. Reusable DRD or Sub DRD in Decision Model and Notation (DMN)
  5. Decision model and Notation – Policy Example
  6. Reuse Business Decision
  7. Simple Workflow using Decisions – Orchestration Simplified
  8. Workflow Engine or Business Rule Engine
  9. Decision as a Service
  10. Modeling Business Logic i.e. Business Processes, Rules, Decisions, Data, Workflow…