Get Started with Decision Management using DMN
Learning by Doing: You can use our free online simulator to execute DMN decision tables that you create.DMN Online Simulator
Create and deploy DMN decision tables in the cloud, and call them from your application via REST.DMN in the Cloud
Decision Model and Notation (DMN) is an industry standard for modeling and executing decisions that are determined by business rules.
DMN has been published in 2015 and is currently seeing a very quick adoption. These are the reasons:
This tutorial provides a quick introduction into DMN, as it is defined in version 1.1.
We should begin our DMN tutorial with a rather simple decision table:
Let's assume we have invited some guests for dinner. The question is, which dish we should prepare. In this example, we follow a very simple decision logic: Depending on the current season, we decide on the dish. If it's Fall, we will go for spareribs, in Winter for roastbeef and so on.
Let's look at the elements in this example:
Simple enough, isn't it? Of course there is more to DMN, but the basic principles are indeed very straight forward.
In many cases a rule will not only consist of one condition, but a combination of conditions. We can express that by adding input columns to the decision table:
In this case we may want to consider guests that are vegetarian. Regardless of the season, we cannot serve them any meat. Fortunately, we always have some pasta available. By combining the two input columns "Season" and "Vegetarian Guests", we have made sure that the first four rules can only evaluate to true, if the guests are not vegetarian. Rule number 5 has a "-" in the input entry that checks the season, and this means that it can be any season, as long as the guests are vegetarians, they will get pasta.
As you can see, the combination of input entries in a rule (i.e. a table row) always follow an AND logic: "If it's fall and my guests are not vegetarian, I will serve spareribs."
Now that you have a basic understanding of a decision table structure, let's take a closer look at possible input entries. It's quite simple to say that certain data should be compared to certain strings (like the fact, that the season should be summer). But DMN offers more advanced concepts for checking input entries. Part of the DMN standard is the Friendly Enough Expression Language (FEEL).
FEEL defines a syntax for expressing conditions that input data should be evaluated against. For example, you can describe in FEEL that a certain input data should be
To get a first idea, please have a look at the example below:
The first thing you'll notice are two additional rows with grey cells. These rows describe technical details that the decision engine needs in order to execute the decision. The first one contains expressions that - in this case - simply refer to variable names, namely season, guestCount and desiredDish. The second one tells the engine the type of the respective outcome of the expression, in this case string and integer.
In the first examples those rows were hidden, in order to not overwhelm you right upfront. But in fact, those types are important, because they determine which FEEL expressions are available for the input entries.
Let's look at each rule, i.e. at each row:
As you probably guess already, this is just the tip of the iceberg. There is much more that you can express in DMN decision tables, as we describe in the DMN Reference Guide.
Perhaps you're thinking:
Hey, why should I use DMN anyway, I can express those rules with BPMN gateways!
If we express the example above in BPMN, it looks like this:
The sorrow is obvious: It's way more verbose to express rules in BPMN, especially when there are several conditions to consider. The diagram becomes complex and hard to maintain.
That is why BPMN includes a so-called business rule task, which should better be named decision task in a later version of the BPMN standard: That task refers to a decision that needs to be made, and the outcome of the decision allows the subsequent exclusive gateway to route the flow, as you can see in the example below.
During modeling as well as execution, we can link the task "Decide Dish" to the DMN decision table, that will be executed when the decision should be made, and the result will then determine the further flow in BPMN.
In this particular example, you could question the use of the flow routing anyway. There are six tasks that are about preparing a meal, the only difference being the kind of meal. There is not apparant advantage of having those six distinct tasks. An alternative pattern would be below:
It's too easy, right? But in this case, it's in fact an appropriate pattern.
Combining BPMN with DMN is a very reasonable approach. Unfortunately, it is not yet standardized by OMG. This means, that a reference from a BPMN business rule task to a DMN decision is always vendor specific.
BPMN is great for processes that are structured, but not for less structures activities. This is where CMMN kicks in. Again, it makes a lot of sense to combine this OMG standard with DMN. For example like this:
Preparing a nice dinner with friends is an art of its own, which demands a real knowledge worker.
In this CMMN case, we will need to invite our guests, for obvious reasons. We might need to prepare the terrace for eating outside. This is determined by the entry criterion (the little diamond on the left edge of the human task), that points to a sentry, where a decision table result is evaluated. The decision table could look like this:
You may notice that the hit policy in this example is not "unique", but "first" (marked as "F"). This means that the decision engine will evaluate the rules and stop evaluating once it has found a rule that applies. In this case this makes sense, because the rules 2 and 3 both apply, if it is colder than 20° C and the rain propability is 50% or higher. Setting the hit policy to "unique" would therefore not be correct.
As with BPMN, the OMG has not yet standardized the way that CMMN and DMN can be combined. The example in this tutorial is therefore based on a proprietary extension that Camunda offers.
If you want to discuss and analyze complex decisions, that may be composed of other decisions, decision requirements diagrams (DRD) can be helpful. This is a quite simple notation defined in the DMN standard, that basically concists of
There are a few more symbols in the DRD notation, however the most relevant ones are these three. We should look at an example:
Let's assume that for our dinner, we also need to decide the beverages we want to serve. This decision should be based on the dish we will prepare and also consider children. The decision table could look like this:
You will notice that this table has a "C" in the upper left corner, instead of the "U" you have seen in the previous examples. The C stands for Collect, which is an other hit policy, and it means that more than one rule could be true, which would lead to a list of output values.
For example, if we will have spareribs, and our guests come with children, we will serve water, apple juice and the famous Aecht Schlenkerla Rauchbier.
Obviously, we need to determine the dish we will prepare, before we can decide the beverages. And this relation is what you can describe in a DRD, like we did in this example:
Camunda BPM supports modeling and execution of DMN, together with BPMN and CMMN. You can find more information about the DMN support in the documentation: