BPMN vs DMN: Key Differences and How to Use Them Together

BPMN describes how work moves through a process. DMN describes how a decision is made from the information available. Used together, they help you show both what happens and which rules determine the outcome.

Consider a customer returning an online purchase. The company needs a process for receiving the request, handling the returned product, and issuing a refund. It also needs rules for deciding whether the return is eligible. These are closely related modeling problems, but they deserve different explanations.

In this article, we will model that example step by step. You will see when BPMN is sufficient, what a DMN Decision Table adds, and how the two models work together.

Key Takeaways

• BPMN models the flow of work, including Activities, Events, and alternative paths.
• DMN models Decisions, their Information Requirements, and the logic used to determine results.
• Simple routing conditions can remain in BPMN. You do not need a separate DMN model for every Gateway.
• A Decision Table can make combinations of business rules easier to review and change.
• A BPMN process can evaluate a DMN Decision and use its result to determine the next step.
• Correct decision logic still needs suitable Input Data, testing, and a clear business policy.

BPMN vs DMN at a Glance

Business Process Model and Notation (BPMN) and Decision Model and Notation (DMN) are complementary standards maintained by the Object Management Group (OMG). They can be used together or independently.

The distinction becomes useful when the workflow is relatively stable but its business rules change. A retailer may continue receiving and refunding returns in the same way while changing the eligibility policy.

DMN is broader than Decision Tables. A Decision Requirements Diagram shows the information and other Decisions needed by a Decision. The detailed logic can use Decision Tables or other expressions. Here, we will focus on one Decision and one Decision Table.

A Product Return Example

Imagine a fictional online retailer with a voluntary return policy. We will use simplified company rules for teaching, rather than attempt to describe consumer rights or every possible return situation.

For this example, a return is eligible only when all three conditions are met:

1. The customer submits the request within 30 days of delivery, including day 30.
2. The product belongs to a category that allows returns under this policy.
3. The product is unopened.

Otherwise, the result is Not Eligible under this policy.

We will use three inputs: Days Since Delivery, Returnable Category, and Unopened. The first is a nonnegative whole number, measured when the request is submitted. The other two are Boolean values: true or false.

The initial assessment uses the condition reported by the customer. Physical inspection happens later. A positive eligibility result authorizes the return to proceed; it does not prove that the received product matches the request.

The Process therefore needs to assess the request, tell the customer what to do, receive and inspect the product, and issue a refund when appropriate. Our diagrams will keep the later handling steps collapsed so we can concentrate on eligibility.

Modeling the Return Process Using BPMN

We can start with a straightforward BPMN Process. A return request arrives, the company assesses eligibility, and an Exclusive Gateway separates the eligible and ineligible paths.

On the eligible path, the company handles the authorized return. This includes sending instructions, receiving the product, checking it, and issuing a refund if the checks succeed. On the other path, the company informs the customer that the request is not eligible.

Figure 1. The BPMN Process shows where eligibility is assessed and what happens after the result is available.

The diagram makes the workflow understandable, but the Task name does not explain the policy. A reader still needs to know how eligibility is determined. That detail could initially be recorded in a procedure or attached documentation.

An Exclusive Gateway routes the Process using conditions on its outgoing Sequence Flows. Those conditions can contain expressions, so BPMN is capable of representing conditional logic. In this example, they can simply test whether the assessment result is Eligible or Not Eligible.

This first Process is useful even before we introduce DMN. Its level of detail is suitable for discussing the overall handling of a return.

When Business Rules Become Difficult to Maintain

Suppose we want to show the eligibility policy directly in the Process Diagram. We could replace the assessment with a series of questions:

• Was the request submitted within 30 days?
• Does the product category allow returns?
• Is the product unopened?

A failed condition leads to rejection. When all three conditions pass, the return can proceed.

Figure 2. The same eligibility policy can be expressed through Process branches, but each additional condition adds detail to the workflow.

Three conditions are still manageable. The challenge becomes clearer when the policy grows. Perhaps some categories have different return periods, or a holiday campaign changes the deadline for certain purchases. Reviewing the policy now means following more branches and checking their combinations.

Before adding another Gateway, ask whether the new branch represents different work or simply another condition used to calculate the same result.

If a branch introduces a supervisor review, it represents a meaningful Process step. If it only checks another fact already available in the request, a Decision Model may provide a clearer place for that rule.

There is no fixed number of Gateways at which DMN becomes mandatory. The practical question is whether people can understand, test, and maintain the rules comfortably in their current form.

Modeling Return Eligibility Using DMN

We will name the Decision Determine Return Eligibility. It takes the three inputs defined earlier and returns one of two text values: Eligible or Not Eligible.

Before defining the rules, we should identify the information this Decision needs. In DMN, we can show this using a Decision Requirements Diagram (DRD).

Start With the Decision Requirements Diagram

Our DRD contains one Decision and three Input Data elements:

• Days Since Delivery: The number of days between delivery and submission of the return request.
• Returnable Category: Whether the product belongs to a category that allows returns.
• Unopened: Whether the customer reports that the product is unopened.

The Decision is represented by a rectangle. Each Input Data element is represented by a shape with rounded ends. Information Requirements, drawn as solid lines with filled arrowheads, point from the Input Data elements toward the Decision that requires them.

Figure 3. The DRD shows which information is required to determine return eligibility.

The DRD answers “What information does this Decision need?” It does not yet explain how that information produces an eligibility result.

These connections are dependencies, not a sequence of work. Unlike BPMN Sequence Flows, they do not describe which Activity happens next.

Define the Logic With a Decision Table

We can now describe the logic of Determine Return Eligibility using a Decision Table.

The Decision Table belongs to the Decision shown in the DRD. It uses the three inputs to determine the value of the output, Eligibility.

Each row represents a rule. A rule matches when all its input conditions are satisfied.

Figure 4. The Decision Table defines how the required inputs determine return eligibility.

The DRD and the Decision Table provide two complementary views of the same Decision: the DRD shows its information requirements, and the Decision Table defines its logic.

How to Read the Decision Table

The dash means that an input does not affect that rule. In Rule 1, a request submitted after 30 days is ineligible regardless of the category and product condition. The dash does not mean that the data is missing.

Each row combines its input conditions. Rule 3, for example, matches when:

• The request is within 30 days.
• The category allows returns.
• The product has been opened.

Its output is Not Eligible.

The entries use simple DMN expression syntax: comparison tests such as <= 30, Boolean values such as true, and quoted text outputs such as "Eligible".

DMN defines FEEL, the Friendly Enough Expression Language, for expressing decision logic. Values such as true and false retain their lowercase spelling because they are part of that syntax.

Reading Two Return Requests

For the first request, the product was delivered 12 days ago, its category allows returns, and it is unopened. Rule 4 matches, so the result is Eligible.

For the second request, the same kind of unopened product was delivered 42 days ago. Rule 1 matches, so the result is Not Eligible. The product’s otherwise acceptable condition does not change the deadline rule.

This is useful during a business review. Participants can take an actual or proposed case, identify the matching row, and discuss whether the result reflects the intended policy.

Why the Unique Hit Policy Fits This Example

A Hit Policy defines how a Decision Table handles matching rules.

Unique means that at most one rule may match a given set of inputs. It does not mean “use the first matching row.”

Our four rules are mutually exclusive:

• Rule 1 covers requests after day 30.
• Rule 2 covers requests within 30 days for nonreturnable categories.
• Rules 3 and 4 divide the remaining cases by product condition.

They also cover every combination within our stated input domain. That completeness comes from how we wrote the rules; the Unique Hit Policy alone does not guarantee it.

The Decision Table is intentionally limited to valid, complete inputs. A missing delivery date or unknown product condition needs separate handling, such as asking for more information. We should not silently interpret missing information as a negative eligibility result.

Testing the Policy Before Using It

The threshold deserves particular attention. Because day 30 is included, a qualifying request on day 30 should be eligible, while the same request on day 31 should not be.

These examples test the deadline boundary and each reason for rejection. A complete implementation should also check input validation and the surrounding Process behavior.

Using BPMN and DMN Together

We can now return to the original BPMN Process and make the eligibility assessment explicit as a Business Rule Task.

BPMN defines this Task type as a way for a Process to supply inputs to a business rules engine and receive results. A DMN engine can evaluate our Decision. The Process then uses the returned eligibility value to select the appropriate path.

Figure 5. The Business Rule Task evaluates the eligibility Decision. The Gateway uses its result to route the Process.

The three responsibilities are now easy to distinguish:

For an executable solution, the Decision reference, input mapping, and result mapping need configuration in the chosen platform. Adding a table icon to a Task does not establish that connection by itself.

A Business Rule Task is appropriate here because we are proposing automated evaluation. If an employee makes the assessment, the Process should show the human Activity appropriately; the Decision Model can still explain the rules they use.

Changing the Policy Without Redrawing the Workflow

Suppose the retailer extends the return period from 30 to 45 days for all products covered by this simplified policy. We update the deadline tests in all four rows of the Decision Table and retest the boundaries, including days 45 and 46.

The DRD remains unchanged because the Decision still needs the same three inputs. The BPMN Process also follows the same steps: assess eligibility, handle an authorized return, or inform the customer of rejection. A request submitted on day 42 may now produce a different result, but the overall workflow does not need to be redrawn.

This separation makes the scope of the policy change easier to see. It does not remove the need to approve and deploy the change, or decide which policy version applies to existing requests.

If the new policy also introduces a supervisor review, the BPMN Process will need to change as well.

Choosing Between BPMN and DMN

Start with the business question and the people who need to review the model.

A small Decision Table may be easier for a policy owner to check than several branches. Conversely, introducing a separate model for an obvious, stable condition can create unnecessary maintenance.

DMN also does not require a large Decision Table for every Decision. As a model grows, several smaller Decisions may explain the logic more clearly than one table containing every possible combination.

Common Mistakes to Avoid

Treating BPMN and DMN as Competing Alternatives

Choosing DMN for eligibility does not remove the need to show what happens to an approved return. Equally, a Process Diagram does not automatically explain how its eligibility assessment works.

Select the representation that makes each question clear.

Reading a DRD as a Process Flow

An Information Requirement indicates that a Decision needs information. It does not describe a handoff, a waiting point, or the next Activity.

Use BPMN to explain the sequence of work and DMN to explain Decision dependencies and logic.

Assuming Every Gateway Needs a DMN Decision

In our combined example, the Gateway remains useful. It tests the eligibility result and selects the appropriate path.

Moving that simple routing test into another Decision would add little value. Separate the substantial policy logic where doing so improves the model.

Overlapping Rules in a Unique Decision Table

Suppose we changed Rule 2 to reject every nonreturnable category, regardless of the number of days. A late request in that category would match both Rules 1 and 2.

That would violate the Unique Hit Policy even though both rows return Not Eligible.

Keep the rules disjoint, as in our Decision Table, or deliberately choose a different Hit Policy when the business logic requires overlapping rules.

Assuming Every Input Will Match a Rule

Removing Rule 3 would leave an unanswered case: a returnable product requested within 30 days that has been opened.

The remaining rows would still be nonoverlapping, but they would not be complete. Check coverage separately from overlap.

Mixing Eligibility With the Entire Refund Process

Eligibility determines whether the request can proceed under the stated policy. Receiving the package, inspecting its contents, and transferring money are further work.

Keep that distinction visible so a positive Decision result is not mistaken for a completed refund.

Combining Too Many Decisions in One Table

Return eligibility, refund amount, and responsibility for shipping costs are different questions. Combining all of them prematurely can produce a Decision Table that is difficult to review.

Begin with a clearly defined result and add separate Decisions when needed.

Frequently Asked Questions

Does DMN Replace BPMN?

No. DMN describes Decisions and their logic; BPMN describes Processes. In our example, DMN determines eligibility while BPMN describes how the company handles the request and the returned product.

What Is the Difference Between a DRD and a Decision Table?

A Decision Requirements Diagram shows the information and other Decisions required by a Decision. A Decision Table defines rules for producing results from inputs. They describe different aspects of the same Decision Model.

Can BPMN Represent Business Rules Without DMN?

Yes. BPMN can use conditional expressions, and an assessment Task can be supported by documented rules or other implementations.

DMN becomes useful when a separate, explicit Decision Model makes the logic easier to understand and maintain.

What Is the Difference Between a Gateway and a DMN Decision?

In our combined example, the DMN Decision determines eligibility from three inputs. The Exclusive Gateway evaluates the conditions on its outgoing Sequence Flows to select the eligible or ineligible path.

The Decision provides a result; the Gateway controls which path the Process takes.

Can DMN Be Used Without a BPMN Process?

Yes. A Decision Model can be used independently, for example by an application that needs an eligibility result. It does not require a BPMN Process to use its decision logic.

When Is a Decision Table Unnecessary?

A Decision Table may add little value when a Decision consists of one straightforward condition that is already clear where it is used.

Consider reuse, review needs, and expected policy changes before creating a separate model.

Does Creating a DMN Model Automatically Make a Decision Executable?

No. Automated evaluation needs suitable decision logic, defined inputs and outputs, and an engine that supports the model.

The application or Process must supply the inputs and handle the result. A picture of a Decision Table is not an executable deployment.

Why This Matters

The return example gives the Process owner and the policy owner something concrete to review.

The BPMN model explains what happens to the customer’s request. The DRD identifies the information needed for the eligibility Decision. The Decision Table shows which combinations qualify.

Separating these concerns also makes changes easier to discuss. A revised deadline affects the decision rules. An additional inspection or approval step affects the Process. Some changes affect both, but the models help the team identify where the work belongs.

When reviewing your own Process, look for a Task such as “Assess Request,” “Calculate Price,” or “Determine Eligibility.” If its rules are difficult to explain from the existing documentation, that is a useful place to try a small DMN model.

Why Trust This Article?

I am Filip Stachecki, a consultant and trainer with more than 20 years of experience in software engineering, business analysis, and professional education. Since 2013, I have contributed to OMG certification programs, including defining exam scopes and co-authoring official OCEB 2, OCUP 2, and BPMN exam questions.

The language explanations in this article refer to the OMG BPMN and DMN specifications. The return policy and worked examples are teaching examples designed to make the distinction between Process flow and decision logic practical.

About eduMAX

eduMAX is an OMG Accredited Training Provider offering training and certification preparation in modeling. My materials focus on understanding how to apply modeling concepts, supported by practical examples and clear explanations.

Explore eduMAX training and practice materials or read more articles on the eduMAX blog.

Specification References

• OMG BPMN 2.0.2: Sections 10.3.3 and 10.6.2.
• OMG DMN 1.5: Clauses 6-8 and 10, particularly Sections 8.2.8 and 8.2.11.