Decision Modeling with DMN: Guide and Examples | Decisions
Decisions Blog
Decision modeling with DMN: a practical guide with examples.
Key takeaways:
Decision modeling defines how a business decision is made: the question it answers, the inputs it needs, and the logic that produces the outcome.
Decision Model and Notation (DMN) is the standard for decision modeling. It works alongside BPMN by keeping decision logic out of process diagrams.
A good decision model breaks a decision into verifiable inputs and sub-decisions, then captures the logic in decision tables that business and IT can both read.
Decision modeling is the practice of defining exactly how a business decision gets made: the question it answers, the information it needs, and the logic that turns that information into an outcome. Decision Model and Notation (DMN) is the industry standard for drawing those models.
Behind every business process is a web of decisions. Data moves through a series of conditions, taking one path or another until it reaches a conclusion. To most people, the code that makes those choices reads like a foreign language, which makes it hard for business teams and developers to agree on how a decision should work. Decision modeling closes that gap.
In this guide, we cover what decision modeling is, how DMN works with BPMN and CMMN, why decisions are modeled separately from processes, and how to build your own decision model, with examples and decision tables you can adapt.
What is decision modeling?
Every organization makes repeatable decisions: whether to approve a loan, what price to show a customer, or whether an order can be fulfilled. Decision modeling captures the logic behind those decisions in a structured, visual form, instead of leaving it in spreadsheets, policy documents, or code.
The decision itself, phrased as a question with a defined set of possible answers.
The inputs the decision depends on, such as customer data, policy limits, or dates.
The logic that connects inputs to outcomes, often written as a decision table.
Because the model is visual, business teams can review and change the logic, and developers or a rules engine can run it exactly as written.
What is Decision Model and Notation (DMN)?
Decision Model and Notation (DMN) is one of three complementary standards from the Object Management Group (OMG), a global consortium that standardizes the languages behind process management systems.
DMN works as a translator. It turns the code behind complex decisions into diagrams and tables that everyone, from executives to developers, can read. It's a user-friendly way to express the if-this-then-that business rules.
How DMN works with BPMN and CMMN.
DMN sits alongside two other OMG standards. Together they give business users and IT professionals a shared set of languages for designing workflows and automations. A simple example shows how each one fits: an event planner organizing a party.
Business Process Model and Notation (BPMN).
BPMN maps the overall flow of a predictable, repeatable process. BPMN diagrams show where a process starts, where it ends, and the sequence of steps in between. Twelve weeks before the party, an automated process collects RSVPs, creates a seating chart, and asks guests about their food preferences.
Case Management Model and Notation (CMMN).
Not every process follows fixed steps. CMMN models situations that break from the norm and need a knowledge worker to step in. A guest selects "Other" on the food survey and lists an unusual allergy. The system flags the response and alerts the planner to investigate and order a special dish.
Decision Model and Notation (DMN).
DMN zooms in on the logic behind a single step. Where the BPMN diagram says "Create seating chart," DMN defines how it's done, using inputs like guest relationships and age to decide where each person sits.
The building blocks of a DMN model.
DMN models are drawn as a decision requirements diagram (DRD), which shows how decisions, data, and knowledge connect to reach a conclusion. The logic inside each decision is usually defined in a decision table.
Decision requirements diagram elements.
Decision: the outcome your logic produces, phrased as a question, such as "What price should this customer see?"
Input data: the information your logic analyzes to reach a decision, such as a customer's rewards tier.
Business knowledge model (BKM): reusable business logic, such as a store's discount policy, that one or more decisions apply.
Knowledge source: the authority behind the logic, such as a regulation or internal policy.
Decision tables and hit policies.
A decision table lists rules as rows. Each row maps a combination of input values to an output. The hit policy, shown as a letter in the table's corner, defines what happens when more than one rule could match. The most common is U (Unique), where exactly one rule can match any set of inputs.
FEEL.
Friendly Enough Expression Language (FEEL) is the expression language DMN uses to write conditions in a readable way, from simple true or false checks to dates, numbers, and ranges.
Learn more about intelligent decisioning.
Learn how business rules work, how to model rules around your business logic, and what to look for in a rules engine.
1. Define the decision as a question. Ask what needs to be answered, and list every possible outcome. Keep outcomes limited and unambiguous, for example, Yes or No.
2. List the inputs. Identify every consideration that affects the outcome, along with all the possible combinations of values.
3. Map how the outcome depends on each input. For any input that isn't directly observable, define what's needed to produce it as a sub-decision.
4. Continue until every input is backed by verifiable data. The model is complete when no input needs another sub-decision.
5. Write and test the logic. Capture the rules in decision tables, then test them against real cases, including edge cases, before they go live.
Decision modeling example: holiday pricing with decision tables.
Snow Shoppe, an ecommerce store, sells a popular snow globe for $99.99 most of the year. During the holidays, its price depends on the customer's rewards tier. Instead of someone calculating prices by hand, the rules live in a decision table. Code performs the calculation, but sales and marketing teams can see exactly how each price is set.
The business knowledge model is the store's policy: each rewards tier takes another $10 off the list price.
Table: Snow globe price (hit policy: U, Unique)
Columns: Member rewards tier | Snow globe price
Row 1: Gold | 79.99
Row 2: Silver | 89.99
Row 3: None (guest) | 99.99
Before showing a price, the system checks whether the shopper is a rewards member. A Gold member gets $20 off and pays $79.99. A guest pays the standard $99.99.
Now marketing wants a Black Friday promotion: Gold members get an extra $10 off on that day. Instead of rewriting code, the team adds a second input. The output of one decision, the shopper's rewards tier, feeds the next decision, the final price.
Table: Snow globe price with Black Friday (hit policy: U, Unique)
Columns: Member rewards tier | It's Black Friday | Snow globe price
With FEEL, the same model can handle more nuanced conditions, such as: The number of days before a major holiday is greater than a set number. The customer's total spend this year is above a set amount. It's the customer's birthday. The customer has more than a set number of snow globes in their cart.
From decision model to automated decision.
A decision model is most valuable when it runs. A business rules engine executes modeled decision logic inside your processes, so every decision follows the model exactly, and changes take effect as soon as the logic is updated.
In Decisions, teams build decision logic visually with statement rules, truth tables, and matrix rules in the Decisions rules engine, then run it inside the same workflows that use the result. Subject-matter experts own the logic, while IT keeps control of governance and deployment. That's how a decision model becomes decision automation: consistent decisions, made at scale, that anyone on the team can trace back to the model behind them.
Try decision modeling in Decisions.
Build your first decision model and run it in a live workflow, with no code required.
Decision modeling is the practice of defining how a business decision is made: the question it answers, the inputs it needs, and the logic that produces the outcome. Models are usually built with Decision Model and Notation (DMN), so business and technical teams can read and automate the same logic.
What is the difference between DMN and BPMN? +−
BPMN models processes: the steps, their order, and who performs them. DMN models decisions: the logic that determines an outcome at a given step. A BPMN business rule task calls a DMN decision, which keeps process diagrams simple and lets teams change decision logic without changing the process.
What is the difference between DMN, BPMN, and CMMN? +−
All three are Object Management Group standards. BPMN models predictable, repeatable processes. CMMN models cases that break from the norm and need a knowledge worker to step in. DMN models the detailed decision logic behind individual steps in either one.
What are examples of decision modeling? +−
Common examples include loan approvals and KYC checks, dynamic pricing, product recommendations, vacation time calculations, and eligibility checks, such as whether an alcohol order can legally be shipped. Any repeatable decision with defined inputs and outcomes is a good candidate for decision modeling.
15 October 2026
Point Tools vs. Platform: What Happens When Orchestration Isn't Native
