DMN (Decision Model and Notation)

What is DMN?

DMN, short for Decision Model and Notation, is the standard for writing a business decision down so that the person who owns the rule and the software that runs it are reading the same thing. It is maintained by the Object Management Group, the same body behind BPMN, and the two go together: the process model draws the flow of work, the decision model holds the decisions that flow depends on.

The standard gives you two tools: a graphical notation that shows which decisions exist and what they depend on, and an expression language called FEEL that writes the logic itself, most often as a decision table. The decision table entry in this dictionary covers the grid and its hit policies. DMN is the standard around that grid: how a decision is named, where its inputs come from, how it moves between tools as XML, and how an engine has to evaluate it.

Version 1.5, adopted in August 2024, is the most recent formally approved release. Betas of 1.6 and 1.7 have been published since, and engines run ahead of formal adoption: Apache KIE has shipped DMN 1.6 support since April 2026. For a first decision model the version number matters less than the conformance level. Level 3 is the one that means a model is executable, not only drawable.

Why decisions were pulled out of the process model

Draw a discount rule in BPMN and you get gateways. Customer type splits three ways, order value splits four ways, and the diagram meant to show how an order gets shipped is now mostly diamonds. SAP Signavio makes the point with a product discount example: even a fairly simple decision produces a process diagram that is hard to read and prone to inaccuracy. The decision has not disappeared, it has been smeared over the process steps where nobody sees it whole.

The second reason is timing. A process changes when the company reorganises, perhaps once a year. The rules inside it change when a price list moves or a supplier contract is renegotiated. Two things on two different clocks should not live in one file that a developer redeploys every time the sales manager adjusts a threshold. Reuse follows from the same split: a creditworthiness decision used in the quote, order and dunning processes is one decision called from three places, not three copies that drift apart until a customer gets two different answers in the same week.

The two levels of a DMN model

The top level is the decision requirements diagram, or DRD, and it says what is being decided. It holds four kinds of element. A decision is a box that produces an outcome and can require other decisions, so the result of one feeds into the next. Input data is a fact from outside, such as the order weight or the customer's contract status. A business knowledge model is logic you want to reuse in more than one decision. A knowledge source names the authority a rule comes from: a policy document, a piece of legislation, or a person by name.

Camunda's documentation is blunt about the last two: a knowledge source and input data have no execution semantics and are ignored on evaluation. They are in the diagram for the reader, and that is not a weakness. Being able to point at a box and say that a rule comes from the 2025 transport policy and that the transport manager owns it is half the reason to draw the thing.

The lower level is the decision logic, and it says how. Each decision box gets a boxed expression, which in practice is almost always a decision table: the inputs across the top, one rule per row, the outcome in the last column.

FEEL, the Friendly Enough Expression Language, fills the cells. It is defined inside the DMN specification itself and reads closer to a spreadsheet formula than to code. x < 5 and (y > 10 or z > 20) is FEEL, and so is if (5 < 10) then "low" else "high". Trisotech describes the intended author as a typical Excel power user, able to write formulas but not a programmer. In a decision table most cells hold one comparison or one range, so you rarely meet more of the language than that.

A delivery surcharge decision, worked out

A Belgian wholesaler sets a delivery surcharge on four things: whether the customer has a delivery contract, the zone, the service level and the weight. As a DMN decision table it fits in eight rows.

Decision: Delivery surcharge
Hit policy: FIRST

 #  Contract  Zone    Service    Weight    Surcharge
 1  yes       BE      standard   <= 30      0.00
 2  yes       BE      standard   > 30      12.00
 3  yes       BE      express    -         15.00
 4  yes       NL, LU  -          -         25.00
 5  no        BE      standard   <= 30      7.50
 6  no        BE      standard   > 30      15.00
 7  no        BE      express    -         20.00
 8  -         -       -          -         45.00

Four inputs with two, three, two and two possible values give twenty-four combinations. Rows one to seven cover twelve of them. The other twelve fall through to row eight, the catch-all, at 45 euro.

Read that back to the sales manager and something surfaces straight away. A contract customer shipping to Luxembourg pays 25 euro. The same contract customer shipping to Germany pays 45 euro, exactly what a customer with no contract pays. Outside the Benelux, the contract buys nothing. Nobody decided that, it is what the eight rows happen to do. That is the argument for writing a decision as a table rather than as code: the gap was always there, and the format is what made it visible in a meeting instead of in a customer complaint.

How a DMN decision runs, and how a change stays traceable

A DMN engine takes the model and the input values and returns the outcome. It holds no state, waits for nobody, and gives the same answer for the same inputs. That narrow job is why DMN engines exist both on their own, callable over an API, and built into process engines.

Inside a process engine the call is a business rule task in the BPMN diagram. In Camunda the task names the decision by id and says which process variable the result lands in. Even if you never touch Camunda, the next bit is worth copying: the same task declares which version of the decision to run. You can bind it to the latest deployed version, to the version deployed together with the running process, or to the latest version carrying a named version tag.

That is what makes a decision auditable. A rule change becomes a new version of an artefact with a date, an author and a reason, instead of an edit to a line of code inside a release. Store the version and the matched rule id alongside every outcome, and when a customer asks in October why they were charged 45 euro in March, you load the March version of the table, run their March order through it and show them the row. Without the version, the best you can do is guess at what the table said back then.

DMN versus a rule in code or in a BPMN gateway

The three options do the same job. They differ on one dimension that decides everything else: who can change the rule, and who can reconstruct what it did.

A rule in application code. Changing it means a ticket, a developer, a review and a release. Auditing it means reading a diff in a repository the business has no access to, and the effective date is the deploy date, which can be weeks after the day the change was decided.

A rule in a BPMN gateway. Better, because it is visible in a diagram the business can read. Worse in practice past a handful of conditions, because the logic is spread over branches and the combinations you failed to cover are invisible. Changing it means redeploying the process, which reopens the question of what happens to the instances already running.

A rule in a DMN table. The owner opens the table, sees every row at once, changes one cell, and the change becomes a new version with their name on it. The process model is untouched. That is the whole argument for the standard: not that a table looks nicer, but that it puts the rule in the hands of the person accountable for it and leaves a trail behind them.

The trade is two artefacts to keep in step, and a decision with one condition needs none of this. A table earns its place when the combinations are hard to hold in your head, or when the rule changes more often than the software around it.

Where DMN sits next to an LLM

Once a company has a model that can read a contract, the temptation is to let it decide as well: ask it what the delivery surcharge should be, give it the transport policy, skip the table.

Do not, for any decision that has to be reproducible. A DMN table returns the same outcome for the same inputs every time, and the row it matched is written down. A model asked the same question twice can answer differently, and a prompt is not a versioned artefact with an owner. Camunda's own guidance sorts the two the same way: rules fit where decisions are deterministic and where auditing and compliance matter, agents fit where the input is messy or unstructured and where language has to be understood.

For most companies that becomes a division of labour rather than a choice. Let a model read the incoming mail and pull the weight, the zone and the service level out of an unstructured request, then hand those four values to the table. Let it draft a new row, and let it explain in plain language what the existing rules do, which earns its keep once a table has grown to sixty rows and nobody remembers why row nineteen is there. The person who owns the rule then approves the row and the engine executes it. The model works on the inputs and on the explanation. The decision lives in the table.

The same reasoning runs the other way in an agentic process. Every decision you can express as a table should be a table the agent calls as a tool, rather than a judgement left to the model, because that is what keeps the part you have to test down to a size you can actually test.