Skip to main content

BPMN vs. DMN: When to Use Which (and When to Use Both)

· 6 min read
Richard Bízik
Richard Bízik
Founder of QuantumBPM

BPMN and DMN are two of the most-cited OMG standards in business automation, and they're often confused. The short version: BPMN models processes over time. DMN models decisions at a point in time. They're complementary, not competitors. Most non-trivial systems end up using both.

This post walks through what each standard is, where each one fits, the boundary between them, and a worked example of the two working together.

The 30-second answer​

BPMNDMN
Full nameBusiness Process Model and NotationDecision Model and Notation
ModelsA process — a flow of work over timeA decision — inputs to outputs at one moment
Visual primitiveTasks, gateways, events on a flowA graph of decisions plus boxed expressions (often decision tables)
StatefulnessStateful — each instance has a position, variables, historyStateless — given the same inputs, you get the same outputs
Time-aware?Yes — timers, durations, deadlines, recurring schedulesNo — evaluation is instantaneous
Concurrency modelFirst-class — parallel/inclusive gateways, boundary eventsNone — pure expression evaluation
Expression languageFEEL (commonly)FEEL (always)
Typical question"What happens next?""What's the answer?"

If you take only one thing away: a BPMN business-rule task calls a DMN decision. That single pattern is how most systems combine them.

What BPMN models​

BPMN is a flow diagram for work that unfolds over time. It answers questions like:

  • "When an order arrives, what runs first, and under what conditions does the next step run?"
  • "If the customer hasn't responded in 48 hours, what happens?"
  • "Three things need to run in parallel — when they're all done, then what?"

BPMN's primitives are tasks (units of work), gateways (branching and merging), events (things that happen), and structural containers (sub-processes, call activities). Crucially, BPMN is stateful: a process instance has a current position (the tokens on the diagram), variables, and a history. It can wait. It can fail and resume. It can run for weeks.

For more on BPMN itself, see What is BPMN?.

What DMN models​

DMN is for the bit of work that isn't about flow — it's about figuring out an answer. It answers questions like:

  • "Given this customer's age, income, and credit score, what loan tier do they qualify for?"
  • "Given this transaction, is it high-risk?"
  • "Given this clinical input, what's the triage priority?"

DMN's primitives are decisions, input data, business knowledge models, and decision services, organised in a Decision Requirements Graph. The logic inside each decision is a boxed expression — usually a decision table.

DMN is stateless. Given the same inputs, a decision always returns the same outputs. There's no concept of waiting, no concurrency, no time progression — just expressions over inputs. That's a feature: it's what makes decisions cheap to evaluate, easy to test, and trivially auditable.

For more on DMN itself, see What is DMN?.

Where they overlap (and don't)​

Some surface-level overlap can confuse newcomers, so it's worth being explicit:

Both use FEEL. FEEL is the expression language defined inside the DMN spec, but it's used inside BPMN too — for sequence flow conditions, script tasks, and I/O mappings. One language across both surfaces is a significant ergonomic win when you have it. in QuantumBPM, FEEL is the script language for BPMN as well as the expression language for DMN. You can try it in the browser at the FEEL playground.

Both can express conditional logic. You can model if age < 18 reject, else approve as a chain of BPMN exclusive gateways. You can also model a long-running multi-step approval flow inside a single DMN function.
Both are bad ideas. BPMN gateways are the wrong level of abstraction for evaluating a rule set. DMN has no concept of waiting or human tasks. Use each for what it's designed for.

Neither is the other's parent. DMN is sometimes described as "a part of BPMN" — it isn't. They're separate specifications, governed independently, and DMN is genuinely useful even with no BPMN anywhere in the picture. A pure decision API (no process around it) is a perfectly common DMN use case.

How they work together​

The integration point in the BPMN spec is the business-rule task. It's a task that delegates to a decision engine, passes in the current process variables, and writes the decision's output back into the process state. The pattern looks like this:

[Start] → [Service task: fetch customer]
       → [Business-rule task: "Loan Approval"]   ← calls DMN
       → [Exclusive gateway: approved?]
            ├─ yes → [Service task: disburse funds] → [End]
            └─ no  → [User task: notify customer]   → [End]

The DMN side is just a decision (or a small DRG) named Loan Approval with inputs like age, income, creditScore and an output { approved: boolean, tier: string }. The BPMN side handles everything else: pulling data, branching, waiting, escalating, retrying, recording.

In QuantumBPM, the business-rule task invokes registered DMN definitions in-process, so there's no external decision-service round-trip — the BPMN engine and the DMN engine live in the same product and share the same project, identity, and audit history. See the BPMN overview and DMN overview for the supported feature surface on each side.

A heuristic: which one do I need?​

When you're sketching a new system, ask:

  1. Does this thing run over time, with multiple steps that have to happen in some order? → BPMN.
  2. Does this thing involve waiting — for a human, for an external system, for a timer? → BPMN.
  3. Does this thing need to survive crashes, restarts, and resume mid-flight? → BPMN.
  4. Does this thing take inputs and return an answer, with no waiting and no side effects? → DMN.
  5. Are the rules being changed by non-engineers? → almost always DMN, regardless of where they sit.
  6. Does the thing need both — flow and decisions inside the flow? → both, with DMN called from BPMN business-rule tasks.

The mistake is to lean too hard on either side. A pure-BPMN model with twenty exclusive gateways is unreadable. A pure-DMN model that tries to encode "wait for the customer to upload a document" can't. Use the right tool for the right shape of problem.

Where to go from here​

If you want to model a process that calls a decision end-to-end in a single product, start at the platform overview.