Skip to main content

DMN Overview

The DMN surface in QuantumBPM is a Decision Model and Notation engine implementing the DMN 1.5 specification. It runs alongside the BPMN engine in the same product and shares projects, identity, and audit history with it.

DMN is the OMG-published standard for representing operational decisions — the rules that take an input context, apply some business logic, and produce an answer. Models are visual, vendor-neutral, and (because they're spec-compliant) directly executable.

What's supported​

Modeling​

A full DMN 1.5 modeler with the Decision Requirements Graph for laying out decisions and their dependencies, and boxed expression editors for every spec expression type:

  • Decisions — the top-level units that produce an answer.
  • Input data — variables that flow in from the caller.
  • Business knowledge models (BKMs) — reusable invocable logic.
  • Knowledge sources — references to authoritative documentation, not evaluated.
  • Decision services — collections of decisions exposed as a single callable unit.

For element details and validation rules, see Elements.

Decision logic​

Logic inside each decision uses a boxed expression — a typed visual form of an expression. Supported types: decision tables, literal expressions, contexts, lists, relations, function definitions, and invocations. See Boxed expressions.

FEEL​

Every expression — table inputs/outputs, literal expressions, conditions — is written in FEEL (Friendly Enough Expression Language), the small declarative language defined by the DMN spec. Authoring uses a CodeMirror-based editor backed by a dedicated FEEL language server: autocomplete, hover, signature help, semantic highlighting, and inline diagnostics. See FEEL.

Evaluation​

Decisions are evaluated synchronously against an input context, returning per-decision results with the hit rules (for decision tables) and the dependency tree (which upstream decisions this evaluation pulled in). Each evaluation is recorded in execution history. See Evaluation and history.

Versioning​

Every save creates a new immutable version of the definition. There's no separate deploy step — versions are evaluable from the moment they're stored. See Definitions and versioning.

Where to go next​

FAQ​

What is DMN?

DMN stands for Decision Model and Notation — an OMG (Object Management Group) standard for representing operational business decisions. It separates what logic a system applies from how the surrounding process orchestrates calls to that logic, so business analysts can author rules visually while engineers integrate them with code. A DMN model is a directed graph of decisions and their inputs, with each decision implemented as a boxed expression (most commonly a decision table). The notation is vendor-neutral and spec-compliant DMN models are directly executable by any conforming engine.

What's the difference between DMN and BPMN?

They're complementary, not alternatives. BPMN models the process — the ordered series of tasks, events, and gateways that move work through your system. DMN models the decisions inside that process — the logic that takes inputs and produces a single answer. A typical pattern is a BPMN business-rule task that invokes a DMN decision and stores the result in a process variable, which then drives the next gateway. Separating them keeps process modellers focused on flow and rule authors focused on logic, they version independently, and one can change without forcing changes in the other. QuantumBPM runs both engines in the same product and lets a BPMN process call decisions from any DMN model deployed alongside it.

How is DMN different from traditional business rules engines like Drools or IBM ODM?

DMN is a visual, declarative standard — vendor-neutral and spec-defined — whereas most rules engines (Drools, IBM ODM, Red Hat Decision Manager) define their own syntax, semantics, and runtime model. With DMN, the same model is portable across compliant engines, business analysts can read and edit decisions without learning DRL or an engine-specific DSL, and the logic surface is bounded (decision tables, literal expressions, contexts) which limits the kinds of complexity that creep into business rules. Traditional rules engines tend to be more expressive (forward chaining, RETE algorithms, complex agenda groups) but at the cost of authoring complexity, portability, and easy auditing.

When should I use DMN instead of writing rules in code?

Use DMN when the logic is operational decision-making — eligibility checks, pricing tiers, routing rules, scoring, classifications, validations — and especially when business analysts (not engineers) own the logic. The big benefits are: rules are visually auditable, change without code deploys, version independently of the consuming application, can be tested in isolation, and produce execution traces that explain why a particular answer was returned. Stick with code when the logic is performance-critical (sub-millisecond hot paths), heavily intertwined with data-access patterns, or requires advanced control flow (loops, recursion, complex state machines) — though even then, the routing of which code path to take is often a clean DMN decision sitting on top.

What is a Decision Requirements Graph (DRG)?

A Decision Requirements Graph (DRG, sometimes called a Decision Requirements Diagram or DRD) is the top-level visual structure of a DMN model. It shows decisions (rounded rectangles), input data (ovals), business knowledge models (clipped rectangles), and knowledge sources (waved rectangles), with arrows indicating which inputs flow into which decisions. The graph makes the dependency structure of a decision explicit: if you change an upstream decision, the DRG tells you which downstream decisions need re-validation. It's the DMN equivalent of a process diagram in BPMN — the overall map, with the detail logic living inside each decision node.

What's the difference between a decision and a business knowledge model (BKM)?

A decision is a node in the DRG that produces an answer based on its inputs and is invocable by name from outside the model. A business knowledge model (BKM) is reusable logic that decisions can invoke — think of it as a function. BKMs aren't called from outside the model, they're invoked by decisions (or by other BKMs) within the DRG, and the same BKM can be reused across multiple decisions to avoid duplicating logic. In practice: if multiple decisions share a calculation (a tax rate lookup, a credit-score formula), pull it into a BKM and invoke it from each. The decision tells you what answer was produced, the BKM is the reusable rule.

What is a decision service and how is it different from a single decision?

A decision is a single node — one input, one output, one piece of logic. A decision service is a named collection of decisions exposed as a single callable unit, with explicit input data and one or more designated 'output decisions'. Decision services are the right boundary for external callers (a BPMN process, a microservice, an SDK call) — they wrap a coherent set of related decisions behind one API surface, version together, and let you change the internals without affecting callers. A single decision can be invoked directly too, but for anything beyond a one-off rule, a decision service gives you a cleaner contract.

Which DMN version does QuantumBPM support?

DMN 1.5, the current OMG specification. That includes all of: the Decision Requirements Graph, every boxed expression type (decision tables, literal expressions, contexts, lists, relations, function definitions, invocations), the full FEEL expression language, all DMN 1.5 hit policies for decision tables, and the decision service and BKM constructs. Authoring uses a CodeMirror-based editor backed by a dedicated FEEL language server with autocomplete, hover documentation, signature help, and live diagnostics.

What are boxed expressions in DMN?

A boxed expression is the visual, typed form of a DMN expression — every decision's logic is implemented as one. The DMN spec defines seven types: decision tables (rows-and-columns rules with a hit policy), literal expressions (a single FEEL expression), contexts (named key-value pairs, like a small struct), lists (an ordered collection), relations (a tabular list of contexts — essentially a typed table), function definitions (reusable lambdas, the implementation of a BKM), and invocations (calling a BKM or function with named arguments). The 'boxed' name comes from the visual rendering: each expression type has a standard nested-box layout that makes its structure explicit. QuantumBPM supports all seven.

How do I call a DMN decision from a BPMN process?

Inside the BPMN model, add a <bpmn:businessRuleTask> and configure the embedded DMN mode with <quantum:calledDecision decisionId="..." resultVariable="..."/>. The engine evaluates the named DMN decision synchronously when the token reaches the task and stores the result in the variable. Input mappings on the task feed scope variables to the decision's input data, output mappings extract specific fields from the result for downstream use. By default the latest deployed version of the decision is used, pin a specific version with bindingType="version" version="N". See Business rule task for the full shape.

How does DMN versioning work in QuantumBPM?

Every save creates a new immutable version of the definition — there is no separate deploy step, so versions are evaluable from the moment they're stored. Callers can reference a decision by its latest version (the default — picks up new versions automatically as you save) or pin to a specific integer version (the safer pattern for production, since logic changes don't silently affect running consumers). Older versions remain queryable in execution history, so an evaluation recorded against version 5 still resolves correctly even after version 12 becomes the latest. See Definitions and versioning for the addressing rules.