Hands‑On Exercise: Build, Compare, Evaluate

Modeling isn’t about following a checklist—it’s about building clarity. When you model a real business process, the choice between BPMN and CMMN isn’t just technical. It shapes how teams understand, execute, and adapt work. Too often, analysts default to BPMN because it’s familiar. But over-structuring a complex, adaptive scenario with BPMN leads to brittle models that don’t reflect reality.

That’s where this exercise becomes essential. It’s not just about drawing diagrams. It’s about experiencing the difference in how each notation handles uncertainty, control, and collaboration. You’ll build the same business scenario in both BPMN and CMMN using Visual Paradigm—then compare readability, flexibility, and maintainability.

This isn’t theoretical. I’ve seen teams waste weeks trying to enforce a rigid BPMN flow on a claim investigation. The result? A 30-step process with 12 exception paths that no one can read. Shifting to CMMN didn’t reduce structure—it reorganized it around the real drivers: case context, knowledge, and adaptive tasks. That shift saves time, reduces errors, and builds trust.

By the end of this exercise, you’ll have a clear framework for when to use each notation. More importantly, you’ll have a practical benchmark for evaluating models—because the best models don’t just follow rules. They reflect how work actually happens.

Step 1: Define the Scenario

Start with a realistic, real-world business scenario: Insurance Claim Investigation.

Here’s the core context:

• A customer submits a claim after a car accident.
• The claim is initially auto-validated for completeness.
• If the claim is incomplete, the system routes it to an agent for data collection.
• Once complete, the case enters investigation: a mix of automated checks, manual reviews, and field inspections.
• Outcomes vary: some claims settle quickly; others require legal review or fraud investigation.
• Decisions are made by a team based on evidence, not a fixed sequence.

Now, the challenge: model this scenario in both BPMN and CMMN. Use the same data, same actors, same logic—only the notation changes.

Step 2: Model in BPMN

Open Visual Paradigm and create a new BPMN diagram. Name it Claim Investigation (BPMN).

Start with the initial event: Claim Submitted. Use a start event with a message flow.

Add a User Task: Validate Claim Data. Use a rectangular box with an envelope icon.

Now add a gateway: Is Claim Complete?. Use an exclusive choice gateway with two outcomes: Yes → Assign to Investigator, No → Request Missing Documents.

For the path of higher complexity, insert a series of sequential tasks:

• Conduct Vehicle Inspection
• Review Police Report
• Check Prior Claims History
• Assign to Risk Analyst

Add a decision gateway: Is Fraud Suspected?. If yes, route to Fraud Investigation Subprocess—another BPMN subprocess.

Finally, add end events: Settle Claim and Escalate to Legal.

Once complete, evaluate this model using the following checklist:

• Is the flow predictable and linear?
• How many exception paths are explicitly modeled?
• Can the model be updated without re-drawing the entire flow?
• Is the logic clear to a non-technical stakeholder?

Now, pause. This model works *only* if the process is fixed. But in reality, the investigation path shifts based on evidence. The model starts to feel rigid, even if correct.

Step 3: Model in CMMN

Create a new CMMN diagram. Name it Claim Investigation (CMMN).

Start with the case: Insurance Claim Investigation. Use a case box with an optional header.

Add four stages:

• Initial Review — includes tasks: Validate Claim, Request Missing Data
• Field Investigation — includes tasks: Conduct Vehicle Inspection, Review Police Report
• Risk Assessment — includes tasks: Check Prior Claims, Assign to Risk Analyst
• Decision & Resolution — includes tasks: Determine Fraud Risk, Settle Claim, Escalate to Legal

Now define sentries (conditions) that control stage transitions:

• After all data is collected → Enter Field Investigation
• If fraud risk detected → Trigger Fraud Investigation as a subcase
• After risk analysis complete → Enter Decision & Resolution

Set up a case file with key data: Claim ID, Date of Incident, Evidence List, Adjuster Assigned.

Add a task: Update Case Notes — this is a manual, ad-hoc task that can be completed at any time.

Compare this model to the BPMN version. Notice:

• There’s no fixed sequence. Stages are entered based on conditions.
• Fraud investigation is a subcase, not a subprocess. It’s triggered only if needed.
• Knowledge workers can add tasks dynamically—no need to re-plan the whole flow.
• The model reflects the reality of adaptive work.

This model isn’t less structured. It’s differently structured—around control points, conditions, and human judgment.

Step 4: Compare and Evaluate

Now, step back and compare the two models side by side. Use this table to evaluate key dimensions:

Aspect	BPMN Model	CMMN Model
Control Flow	Fixed, sequential	Constraint-based, event-driven
Flexibility	Low — hard to adapt	High — supports dynamic task addition
Readability	Good for routine work	Excellent for complex, adaptive cases
Change Management	Requires rework for new paths	Tasks and stages added dynamically
Best For	High-volume, repeatable processes	Knowledge-intensive, unpredictable work

Ask yourself:

• Which model is easier to explain to a claims adjuster?
• Which one can evolve as new evidence emerges?
• Which one makes it clearer that decisions are context-driven?
• Which one aligns with how the team actually works?

The answer often surprises people. CMMN isn’t “less formal.” It’s more accurate for adaptive scenarios.

But here’s the deeper insight: you don’t have to choose one or the other. In real systems, you’ll often see hybrid models. Use BPMN for the high-frequency, repeatable parts—like validation and routing. Use CMMN to manage the core case investigation.

This is the power of combining both. The best models aren’t always the most rigid or the most free-form. They’re the ones that mirror real-world behavior.

Key Takeaways

After this business analysis exercise, you’ve done more than build two diagrams. You’ve learned to think in two modeling paradigms.

When to use BPMN — for predictable, rule-based workflows like approvals, onboarding, or order fulfillment.

When to use CMMN — for adaptive, knowledge-driven work like investigations, claims, or legal cases.

When to combine them — when a process has both structured and unstructured phases. Use BPMN for the flow, CMMN for the case.

Remember: the goal isn’t to master every symbol. It’s to choose the right tool for the work at hand. BPMN CMMN tutorial isn’t about memorization. It’s about judgment.

And that judgment? It comes from experience, reflection, and yes—hands-on practice.

Frequently Asked Questions

Can I use both BPMN and CMMN in the same project?

Yes, and it’s common in mature organizations. Use BPMN for standardized, repeatable workflows and CMMN for knowledge-centric, adaptive processes. You can embed CMMN case plans inside BPMN subprocesses, or invoke BPMN workflows from CMMN stages.

How do I know which notation to pick for my process?

Ask: Is the sequence fixed? If yes, use BPMN. If the path depends on evidence, decisions, or human judgment, use CMMN. Use the predictability and control test: if the next step isn’t known in advance, CMMN is likely better.

Is CMMN harder to learn than BPMN?

Not necessarily. CMMN uses fewer symbols but introduces new concepts like stages, sentries, and case files. It’s different, not more complex. The real challenge is shifting from a flow-based to a constraint-based mindset.

What tools support both BPMN and CMMN modeling?

Visual Paradigm is one of the few tools that supports both standards in a single environment. It allows seamless integration, model validation, and simulation. Other tools like Camunda or Signavio support one or both depending on the version.

Why is readability important in modeling?

Models are communication tools. If stakeholders can’t read them, they won’t trust them. CMMN often scores better on readability for complex cases because it structures work around events and conditions, not fixed paths.

How often should I re-evaluate my model choice?

Re-evaluate when the process changes significantly—like adding new decision points, introducing new roles, or shifting from manual to automated handling. A model that worked six months ago may no longer reflect reality.