BPMN + DMN: Combining Process and Decision Modeling in Sparx EA

BPMN shows what happens and in what order. DMN shows how a complex decision is made. Model them separately and both get easier to maintain, govern, and automate.

Most process models hide their decision logic. A label on a sequence flow reads if credit score > 700 and employment > 2 years and loan-to-value < 80%, and that works — right up until the rules get complicated or start changing every quarter. DMN (Decision Model and Notation) pulls that logic out into its own model: the notation for rules, conditions, and outputs that BPMN was never designed to carry. In Sparx EA, both live in the same repository through the DMN MDG extension.

Why separate process from decision

Embedding decision logic in BPMN gateways is fine for one or two conditions. It breaks down the moment decisions get real:

• Rules buried in gateway conditions are hard to find, audit, and change.
• Business stakeholders cannot review rules expressed as process conditions.
• When a rule changes — a regulatory update, a product policy shift — finding and updating every affected gateway is error-prone.
• The same logic gets duplicated across multiple process models.

DMN fixes this by giving the decision its own model. The BPMN process calls the decision (“make credit decision”); the DMN specifies how (“apply these rules to these inputs to produce this output”). A business analyst can update the Decision Table without touching the process.

How BPMN and DMN connect in Sparx EA

The bridge between the two notations is the Business Rule Task — a BPMN task marked with a small table icon that says “at this point, invoke this decision.” It links to a DMN Decision element, which in turn is specified by a Decision Table.

To wire it up in Sparx EA: add a Business Rule Task at the decision point in your BPMN diagram, set its Implementation type to DMN, then link it to the DMN Decision element with a Dependency relationship (or via the task's Called Decision property). For executable processes on Camunda or Zeebe, the task configuration also carries the DMN decision key and the input/output variable mappings.

DMN core concepts

Decision. The fundamental DMN element. It takes inputs and produces an output. A credit decision takes credit score, income, debt-to-income ratio, loan amount, and property value, and produces Approved / Declined / Referred.

Decision Requirements Diagram (DRD). The structural view showing how decisions relate to each other and to their input data. A loan DRD might show a Credit Score Decision feeding a Credit Approval Decision, which feeds a Loan Terms Decision.

Decision Table. The most common DMN artifact. Each row is a rule: given these input conditions, produce this output. Hit Policies determine what happens when multiple rules match.

FEEL. Friendly Enough Expression Language — the DMN expression language for conditions and outputs. FEEL is human-readable: credit_score > 700, income * 0.28 >= monthly_payment, ["Approved", "Premium"] includes decision_output.

Input Data. Data that feeds decisions from outside the decision model — from the process context, a database, or a service call.

Decision Tables and Hit Policies

A Decision Table has three parts: input columns (the conditions evaluated), output columns (the values returned when a rule matches), and rule rows. The Hit Policy controls what happens when more than one rule matches.

Hit Policy	Code	Behavior
Unique	U	Exactly one rule must match; others are errors
Any	A	Multiple rules can match but must produce the same output
First	F	First matching rule wins (rules ordered by priority)
Rule Order	R	All matching rules apply, results in rule order
Collect	C	All matching rules apply, results collected (sum, min, max, count, or list)
Output Order	O	All matching rules apply, outputs ordered

Unique is the safest and most common policy for approval decisions. First suits rules with a natural priority order. Collect with sum is the scoring-table pattern, where several rules each contribute to a total.

The Decision Requirements Diagram in Sparx EA

The DRD is the overview that shows the decision architecture — which decisions depend on which, and which input data feeds which decisions.

DRD elements (DMN MDG):

• Decision (rectangle): the decision being made.
• Input Data (rectangle with clipped corners): data from outside the decision model.
• Business Knowledge Model (rectangle with a wavy bottom): reusable decision logic, like a function, that decisions invoke.
• Knowledge Source (ellipse): the authority, policy, or regulation that governs a decision.

Relationships: Information Requirement (solid arrow) — a Decision or Input Data provides information to another Decision; Knowledge Requirement (dashed arrow) — a Decision invokes a Business Knowledge Model; Authority Requirement (dashed arrow with a circle) — a Knowledge Source governs a Decision.

To build one: enable the DMN MDG (Configure → MDG Technologies → DMN), add a Decision Requirements Diagram, drag Decision and Input Data elements from the toolbox, and connect them with Information Requirement arrows.

Worked example: loan approval

The BPMN process (top level): Application Received → Collect Application Data → Retrieve Credit Report (service task) → Evaluate Credit Application (Business Rule Task → calls the DMN Credit Decision) → Exclusive Gateway on the outcome. Approved routes to Generate Offer Letter; Conditional routes to Request Additional Documentation and loops back; Declined routes to Send Decline Notice.

The DMN side specifies how the decision is made. Inputs: Credit Score, Annual Income, Monthly Debt Obligations, Loan Amount, Property Value. Two calculated decisions (Debt-to-Income Ratio, Loan-to-Value Ratio) feed the Credit Decision, which produces Approved / Conditional / Declined via this table:

Credit Score	DTI Ratio	LTV Ratio	Decision
>= 700	<= 0.36	<= 0.80	Approved
[650..700)	<= 0.40	<= 0.85	Conditional
[600..650)	<= 0.43	<= 0.90	Conditional
< 600	–	–	Declined
–	> 0.43	–	Declined
–	–	> 0.90	Declined

This table is the lending policy. When regulators change DTI limits or the product team adjusts LTV criteria, analysts edit the Decision Table — the BPMN process model never moves. Keeping a clean separation between flow and rules is exactly the kind of process modeling discipline that makes a repository governable rather than brittle.

When to model a decision separately — and when not to

The overhead of DMN earns its keep when decisions are complex, changeable, or shared. For a simple “if order value > $1,000, require manager approval,” a gateway label is enough. Getting that judgment right consistently across a team is a capability worth building deliberately.

Frequently asked questions