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

Direct Answer

BPMN models process flow: the sequence of activities, gateways, and events that constitute a business process. DMN (Decision Model and Notation) models the logic inside decisions within that process: the rules, conditions, and outputs that determine a decision outcome. Together they are complete: BPMN shows what happens and in what order; DMN shows how complex decisions are made. In Sparx EA, DMN is supported via the DMN MDG extension: Decision elements, Decision Tables, Decision Requirements Diagrams (DRDs), and FEEL (Friendly Enough Expression Language) for rule expressions. A BPMN Business Rule Task connects to a DMN Decision element to show that the decision logic is specified separately. The classic use case is loan approval: the BPMN process shows application receipt, credit check, decision, and offer generation; the DMN Decision Table specifies the credit scoring rules that produce the decision. Separating process from decision logic makes both easier to maintain, govern, and automate.

Why Separate Process and Decision?

Many BPMN models embed decision logic inside gateways: a label on a sequence flow reads “if credit score > 700 and employment > 2 years and loan-to-value < 80%." This works for simple conditions. It fails for complex decisions with many variables, multiple criteria, and business rules that change frequently.

The problem with embedding decision logic in BPMN:

• Rules buried in gateway conditions are hard to find, audit, and change
• Business stakeholders cannot easily review or validate rules that are expressed as process conditions
• When rules change (regulatory update, product policy change), finding and updating all affected gateways is error-prone
• The same decision logic is often duplicated across multiple process models

DMN solves this by separating the decision into 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”). Business analysts can review and update the DMN Decision Table independently of the process model.

DMN Core Concepts

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

Decision Requirements Diagram (DRD). The structural diagram showing how decisions relate to each other and to their input data. A DRD for a loan approval process might show: Credit Score Decision (requires payment history, credit utilisation, credit age inputs) feeds into → Credit Approval Decision (requires Credit Score output, income, loan amount inputs) which feeds into → Loan Terms Decision (requires Credit Approval output).

Decision Table. The most common DMN artifact. A table where each row is a rule: given these input conditions, produce this output. Decision Tables can have different Hit Policies that determine what happens when multiple rules match.

FEEL. Friendly Enough Expression Language: the DMN expression language for rule conditions and output expressions. FEEL expressions are human-readable: creditscore > 700, income * 0.28 >= monthlypayment, ["Approved", "Premium"] includes decision_output. FEEL is used in both Decision Table cells and in standalone decision expressions.

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

Decision Tables in Detail

A Decision Table has three parts: input columns, output columns, and rule rows.

Input columns define the conditions evaluated for each rule. Each cell in an input column contains a FEEL expression or a literal value to match. For example, an input column “Credit Score Range” might have cells: < 550, [550..650), [650..700), >= 700.

Output columns define the values returned when a rule matches. An output column "Decision" might have values: "Decline", "Refer", "Approve Conditional", "Approve".

Hit Policies determine how the table handles multiple matching rules:

Unique is the most common and safest hit policy for approval decisions. First is used when rules have a natural priority order. Collect with sum is used for scoring tables where multiple rules contribute to a total score.

Decision Requirements Diagram in Sparx EA

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

DRD elements in Sparx EA (DMN MDG):

• Decision (rectangle): the decision being made
• Input Data (rectangle with clipped corners): data coming from outside the decision model
• Business Knowledge Model (rectangle with wavy bottom): a reusable decision logic definition (like a function) that can be invoked by decisions
• Knowledge Source (elipse): the authority, policy, or regulation that governs a decision

Relationships in DRD:

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

In Sparx EA with DMN MDG:

1. Enable the DMN MDG (Configure → MDG Technologies → DMN)
2. Create a new diagram: Model → Add Diagram → DMN → Decision Requirements Diagram
3. Drag Decision elements from the DMN toolbox
4. Drag Input Data elements
5. Connect with Information Requirement arrows to show the data flow

Connecting BPMN to DMN in Sparx EA

The connection point between BPMN and DMN is the Business Rule Task in BPMN: a task marked with a table icon indicating that it executes a decision or business rule.

Connection process in Sparx EA:

1. In your BPMN process diagram, add a Business Rule Task at the decision point (e.g., "Evaluate Credit Application")
2. In the Business Rule Task properties, set the Implementation type to DMN
3. Link the Business Rule Task to the DMN Decision element: in Sparx EA, use a Dependency relationship from the Business Rule Task to the Decision element, or reference it in the task's Called Decision property

The visual connection makes the separation explicit: the BPMN diagram shows process flow; the Business Rule Task is a placeholder that says "at this point, invoke this decision"; the DMN Decision Table shows the actual rules.

For executable processes (Camunda, Zeebe): the Business Rule Task configuration includes the DMN decision key and input/output variable mappings. The process engine calls the DMN engine at runtime, evaluates the decision, and receives the output as a process variable.

Use Case: Loan Approval Process

BPMN process (top level):

1. Start Event: Application Received
2. User Task: Collect Application Data
3. Service Task: Retrieve Credit Report (external API call)
4. Business Rule Task: Evaluate Credit Application → (calls DMN Credit Decision)
5. Exclusive Gateway: Decision outcome?

- "Approved" → Generate Offer Letter → End - "Conditional" → Request Additional Documentation → re-evaluate loop - "Declined" → Send Decline Notice → End

DMN Decision Requirements Diagram:

• Input Data: Credit Score, Annual Income, Monthly Debt Obligations, Loan Amount, Property Value
• Decision: Debt-to-Income Ratio (calculated from income and debt)
• Decision: Loan-to-Value Ratio (calculated from loan amount and property value)
• Decision: Credit Decision (uses Credit Score, Debt-to-Income Ratio, Loan-to-Value Ratio) → output: Approved / Conditional / Declined

Credit Decision Table (Hit Policy: Unique):

This Decision Table encodes the lending policy. When the policy changes: regulators update DTI limits, product team adjusts LTV criteria: analysts update the Decision Table without touching the BPMN process model.

When to Model a Decision Separately vs Inline

Use DMN when:

• The decision has three or more input variables
• Business rules change frequently and independent governance is needed
• The same decision logic applies in multiple process contexts
• Business stakeholders need to review and validate rules without reading BPMN
• The process will be executed on a DMN-capable engine (Camunda, Drools, Trisotech)

Keep inline (BPMN gateway conditions) when:

• The decision is simple: one or two conditions, clearly expressed as gateway labels
• The decision is unique to this process and will not be reused
• The decision logic is stable and unlikely to change
• The process is documentation-only (not executable) and simplicity is valued over completeness

The overhead of DMN is justified when decisions are complex, changeable, or shared. For a simple "if order value > $1000, require manager approval" condition, a gateway label is sufficient.

Frequently Asked Questions

Q: Does Sparx EA support DMN Decision Table editing natively? A: Yes, with the DMN MDG extension installed. Sparx EA renders Decision Tables as editable grids within the element properties dialog. FEEL expressions can be entered in table cells. For complex Decision Tables with many rules, some architects prefer to use a dedicated DMN editor (Camunda Modeler, Trisotech) and import the DMN XML into Sparx EA for documentation purposes.

Q: Can DMN be used without BPMN? A: Yes. DMN is a standalone notation for decision modeling. You can model a complete decision architecture in DRD and Decision Table format without any BPMN process context. Standalone DMN is useful for policy modeling, regulatory compliance documentation, and decision audit trails where the process context is not the primary concern.

Q: What is FEEL and do we need to learn it? A: FEEL (Friendly Enough Expression Language) is the DMN expression language. For simple Decision Tables with straightforward value matching (>= 700, "Approved", [550..650)), FEEL is intuitive: most analysts pick it up in an hour. For complex expressions involving date arithmetic, list operations, or context expressions, FEEL requires more study. The DMN specification includes a full FEEL reference. For most business rule tables, basic FEEL is sufficient.

Q: How does DMN handle decisions that require lookup tables or external data? A: DMN Decision Tables operate on data provided to them: they do not query databases directly. External data (customer data, product data, regulatory tables) is brought in as Input Data from the process context (populated by preceding service tasks in BPMN) or as Business Knowledge Models (reusable lookup logic). If the decision requires current-time data from a system of record, a Service Task in BPMN retrieves it before the Business Rule Task invokes the DMN decision.

Q: Can the same DMN decision be called from multiple BPMN processes? A: Yes. This is one of DMN's primary benefits. A Credit Decision DMN model can be called from a Mortgage Application process, a Personal Loan process, and a Credit Card Application process: all using the same decision logic. When lending policy changes, update the DMN Decision Table once and all three processes are updated.

Q: How do we version control DMN Decision Tables when rules change? A: Treat DMN elements in Sparx EA the same as other controlled artefacts: use package baselines to snapshot the decision model at each major policy update. Tag each rule with effectivedate and policyversion in the rule notes. For executable DMN on process engines, most engines support decision version management: you deploy a new version of the DMN definition and configure which version each process instance uses.

Next Step

Combining BPMN and DMN in Sparx EA turns process models into precise, executable specifications where process flow and decision logic are separately maintained and independently governable. The Amplify engagement includes DMN methodology, Decision Table standards, FEEL expression guidance, and the BPMN-DMN integration configuration in Sparx EA.

Build process and decision modeling capability with Amplify