Translating Between BPMN and CMMN

Estimated reading: 8 minutes 6 views

Most process models start as linear flows—clear, sequential, predictable. But real business work rarely stays that way. Over time, what began as a BPMN process often evolves into something more complex: unscripted decisions, dynamic data dependencies, and unpredictable control. That’s where CMMN steps in—to model the kind of work that defies rigid flowcharts.

Yet many teams don’t realize that you can convert BPMN to CMMN without losing continuity. The real power lies not in choosing one over the other, but in knowing how they can coexist. I’ve seen organizations replace rigid subprocesses with adaptive CMMN cases, only to find that clarity improved, validation became more accurate, and operational flexibility increased.

This chapter dives into how to translate a BPMN subprocess into a CMMN case, preserving logic, data, and stakeholder accountability. By the end, you’ll understand not just the mechanics of conversion, but also when it’s beneficial—and when it’s a distraction. You’ll learn to recognize when hybrid modeling is the right strategy.

Understanding the Translation Goal

Translating between BPMN and CMMN is not about replacing one with the other. It’s about aligning intent. A well-structured BPMN subprocess often contains a tightly controlled sequence of tasks, but it can quickly become brittle when exceptions arise.

CMMN, by contrast, is built for adaptive work. Its case plan model allows for dynamic task triggers, conditional stage progression, and user-driven control—all without rewriting the entire flow.

When you convert a BPMN subprocess to a CMMN case, you aren’t discarding structure—you’re enhancing adaptability. The goal is to maintain alignment with the parent process while giving frontline teams the freedom to respond to real-time conditions.

When Conversion Makes Sense

  • When the subprocess handles unpredictable exceptions or investigative work.
  • When multiple data paths emerge based on user input or external events.
  • When control shifts between departments or roles frequently.
  • When the process is re-executed in different contexts with varying requirements.

These are signs that the subprocess has outgrown BPMN’s fixed control flow. It’s time to model it as a case.

Step-by-Step: Converting BPMN to CMMN

Let’s walk through a real-world example: a loan approval workflow. The initial BPMN model includes a subprocess for “Verify Applicant Documentation.” Over time, this becomes complex—documents vary, missing fields trigger different actions, and decisions depend on risk level.

Here’s how to convert it into a CMMN case:

Step 1: Identify the Core Adaptive Logic

Review the BPMN subprocess and pinpoint where adaptability is required:

  • What conditions trigger different verification paths?
  • Who decides which documents are needed and when?
  • Are there multiple inspection routes based on risk or region?

These are the signals that this isn’t a linear process—it’s a case.

Step 2: Map BPMN Elements to CMMN Constructs

BPMN Element CMMN Equivalent Why It Fits
Subprocess (Verify Documentation) Case Plan Model Encapsulates adaptive workflow
Exclusive Gateway (e.g., “Is risk high?”) Entry/Exit Criteria + Stages Controls when tasks become available
Manual Task (Review docs) Task with human role Mirrors real-world responsibility
Event-based flow (e.g., “Email received”) Event Trigger (e.g., “Document Uploaded”) Enables dynamic progression
Boundary Events (e.g., timeout) Timer Event (in sentry) Handles time-bound actions

This mapping preserves the original intent while unlocking flexibility. The CMMN model doesn’t replace the logic—it restructures it to respond to reality, not assumptions.

Step 3: Define Stages and Milestones

Break the case into logical phases:

  • Document Collection: Gather initial paperwork.
  • Verification Review: Validate completeness and authenticity.
  • Risk Assessment: Trigger additional checks if needed.
  • Final Approval: Route to decision-maker.

Each stage is activated by a sentry condition. For example, “Stage: Verification Review” activates only when “All required documents are uploaded” and “No flagging issues.”

This level of control is far more intuitive than trying to model every path with gateways.

Use milestones to mark critical points: “Documentation Complete,” “Risk Level Confirmed,” “Approval Sent.” These help track progress without forcing rigid sequencing.

Step 4: Link to Parent BPMN Process

After conversion, the CMMN case replaces the BPMN subprocess. The parent process now invokes the case as a subprocess—just like any other sub-process—but with enhanced control.

Use a Call Case task in BPMN to reference the CMMN case. This preserves the hierarchical structure while offloading complexity to the case model.

Make sure all input and output data (e.g., applicant ID, risk score) are passed through the case boundary. Use CMMN case file items to store and share data across tasks.

Why Hybrid Modeling Works Better

After years of modeling in both standards, I’ve learned that the best systems use hybrid modeling—BPMN for predictable, rule-based flows, and CMMN for adaptive, knowledge-intensive work.

Consider this: a customer onboarding process might be 80% BPMN (validations, KYC checks) and 20% CMMN (investigation of anomalies, document disputes).

Hybrid modeling isn’t about complexity—it’s about precision. It ensures that only the parts that need to be dynamic are modeled adaptively, while stable logic remains clear and testable.

When you apply CMMN BPMN translation correctly, you get:

  • Reduced model bloat from unnecessary gateways.
  • Better alignment with how teams actually work.
  • Improved maintainability—changes to logic happen in one place.
  • Clearer role ownership and decision traceability.

It’s not about choosing the “better” notation. It’s about using the right one—where it makes sense.

Common Pitfalls to Avoid

Translating between BPMN and CMMN is powerful, but it’s easy to misuse. Here are the most frequent mistakes I’ve observed:

  • Overusing CMMN: Not every process needs a case. If the path is repeatable and predictable, BPMN is simpler and cheaper to maintain.
  • Ignoring data boundaries: Failing to define how data flows between the BPMN parent and CMMN case leads to traceability issues.
  • Too many sentries: Overloading entry/exit criteria makes the model hard to read. Prioritize conditions that matter most.
  • Misusing stages: Stages should represent clear logical phases, not arbitrary groupings. Each should have a clear trigger and purpose.

When in doubt, ask: “Would a human with contextual knowledge be able to decide the next step without a predefined flow?” If yes, CMMN is likely the right fit.

Expert Insight: When Not to Convert

Not every BPMN subprocess should be converted to CMMN.

If the process:

  • Runs hundreds of times a day with minimal variation.
  • Is fully automated with no human judgment involved.
  • Has no exceptions or alternative paths.

…then converting it to CMMN adds unnecessary complexity. Stick with BPMN.

Remember: CMMN isn’t a replacement for BPMN. It’s an extension for when BPMN reaches its limits.

Frequently Asked Questions

Can I convert a BPMN subprocess to CMMN in Visual Paradigm?

Yes. Visual Paradigm supports both BPMN and CMMN, and allows you to embed a CMMN case as a subprocess within a BPMN model. Use the “Call Case” task to reference the CMMN case. You can also import or restructure existing models using the built-in translation tools.

How do I ensure consistency after converting BPMN to CMMN?

Define clear data boundaries and use shared identifiers (like a case ID or process instance ID) to track the flow. Use the same naming conventions and maintain a cross-reference table between BPMN and CMMN elements. Validate against the original process logic during model review.

Is hybrid modeling only for large enterprises?

No. Even small teams benefit from hybrid modeling. The key is identifying which parts need structure and which need flexibility. I’ve helped startups use CMMN for client dispute handling while keeping onboarding in BPMN—without increasing overhead.

What if I need to convert a large BPMN model to CMMN?

Start with small, high-impact subprocesses—those with frequent exceptions or complex decision points. Convert one at a time, validate with stakeholders, and scale. Don’t try to convert everything at once.

How do sentries in CMMN relate to gateways in BPMN?

Sentries in CMMN are functionally similar to gateways in BPMN but work differently. Gateways split the flow based on a condition at a fixed point. Sentries evaluate conditions continuously and can activate tasks or stages when met—making them more dynamic and responsive to real-time changes.

Can CMMN and BPMN work together in the same process?

Yes. This is the essence of hybrid modeling. A BPMN process can invoke a CMMN case as a subprocess, and both can share data through case files and process variables. This allows you to combine structured control with adaptive execution—exactly where it’s needed.

When used wisely, the CMMN BPMN translation is not just a technical shift—it’s a strategic refinement of your modeling approach. It reflects a deeper understanding: that business processes aren’t just flows. They are conversations between systems, people, and context.

And that’s where real improvement begins.

Share this Doc

Translating Between BPMN and CMMN

Or copy link

CONTENTS
Scroll to Top