Flexibility by Design: Events, Conditions, and Sentries

When a team begins to model a case not as a fixed path but as a responsive, evolving journey, you know they’ve stepped beyond rote notation use into true adaptive design. That shift happens when the case plan no longer follows a script—it listens.

CMMN sentries are the gatekeepers of this responsiveness. They don’t just monitor conditions—they empower people. When a case worker sees a task unlock only after a document is uploaded or a trigger fires, that’s sentry logic in action.

This chapter walks you through how entry and exit criteria, event listeners, and sentries transform static models into intelligent, knowledge-driven systems. You’ll learn to apply CMMN flexibility in real workflows, avoid common modeling missteps, and design cases where people and systems collaborate dynamically.

What Are CMMN Sentries?

CMMN sentries are conditions that control the activation or deactivation of case elements—tasks, stages, or milestones. They aren’t passive filters. They’re active decision points that react to real-world changes.

Think of them as the “when” logic behind a case’s behavior. Unlike BPMN gateways that control flow paths, sentries in CMMN govern when an element becomes available—making them central to adaptive process design.

The most powerful aspect? Sentries are reactive. They can be triggered not just by time or data, but by events—like a new email arriving or a system alert being raised.

Types of Sentries

• Entry Criteria: Determines when a task or stage becomes available for execution. Must be true before the element is activated.
• Exit Criteria: Defines when a task or stage can be completed. Ensures all required work is done before moving forward.
• Event-based Sentries: Activate or deactivate based on external triggers—like a message received, an email sent, or a data update.

How CMMN Event Handling Enables Adaptive Cases

Real cases don’t follow rigid scripts. They evolve. A medical diagnosis, an insurance claim, a legal investigation—each unfolds differently based on new information.

CMMN event handling makes this possible. By tying sentries to events, the case adapts in real time. A sentry might wait for a “Document Uploaded” event before enabling the next review task. Or it might be triggered when a new audit finding is flagged.

Consider a fraud investigation case. The system monitors transaction logs. When a high-risk transaction is detected, an event fires. The sentry linked to that event checks if the case is open and triggers the “Investigate Suspicious Activity” task. No manual check needed. The system responds dynamically.

Key Advantages of CMMN Event Handling

• Real-time responsiveness: Cases adapt instantly to new data, reducing delays.
• Reduced manual oversight: Workers aren’t forced to poll for changes—they’re notified.
• Scalability in complex workflows: Multiple event sources can be handled without cluttering the model.

These capabilities make CMMN flexibility ideal for domains where unpredictability is the norm—legal, healthcare, cybersecurity, and compliance.

Designing Effective CMMN Sentries: Best Practices

Not every sentry needs to be complex. The key is clarity and maintainability. Overly granular logic becomes hard to validate. Too little, and you risk missing critical triggers.

Here’s how I’ve seen teams succeed:

1. Start with business impact: Ask: what happens if this sentry fails to trigger? Prioritize based on risk and consequence.
2. Use clear, natural language: Avoid nested logic in sentry conditions. “If document type = invoice AND amount > 10,000” is clearer than a Boolean tree.
3. Anchor to data sources: Define where the condition’s inputs come from—e.g., “the case file field ‘Invoice Status’” or “a message from the CRM system.”
4. Test with real scenarios: Simulate edge cases—what if the event arrives out of order? What if the required data is missing?

Common Pitfalls to Avoid

• Overusing event-based sentries: Too many event triggers can make the model chaotic. Use only where responsiveness is truly needed.
• Ignoring timeout conditions: A sentry waiting for an event should have a timeout or escalation path—otherwise, the case can stall.
• Confusing sentries with gateways: Sentries control activation. Gateways control flow. Mixing them creates confusion in execution.

Comparing CMMN Flexibility with BPMN Control

While BPMN excels in predictable, repeatable processes, CMMN shines in adaptive, knowledge-driven scenarios. The difference lies in who controls the flow.

BPMN is procedural. It says: “Do A, then B, then C.” CMMN is reactive. It says: “Do X when the condition is met.”

When modeling a loan approval process, BPMN may define a strict sequence: application → credit check → underwriting → approval. But in a complex case like an investigation, that sequence can’t be assumed.

CMMN flexibility allows the case to reorganize itself. If new evidence emerges, the system triggers a sentry that reopens the “Evidence Review” stage. The path isn’t fixed—it’s emergent.

Aspect	BPMN	CMMN
Primary Control Mechanism	Sequence flow	Entry/Exit Criteria, Event Listeners
Adaptability	Low (fixed path)	High (dynamic activation)
Use Case	Standardized, rule-based workflows	Unpredictable, knowledge-intensive tasks
Event Handling	Event subprocesses	Native event-based sentries

BPMN is like a train timetable. CMMN is a taxi dispatch system—both get people where they need to go, but in different ways.

Practical Example: Fraud Investigation Case

Imagine a financial institution detecting a suspicious transaction. The case is opened in CMMN. A task named “Verify Transaction Authenticity” is blocked by an entry criterion:

IF "Transaction Amount" > $50,000
AND "Risk Score" ≥ 90
AND "Transaction Location" ≠ "Customer’s Usual Location"
THEN activate task

Once activated, the task waits for evidence. A new event arrives: “New email received: Fraud Alert – 12345.” The sentry detects this event and triggers a new task: “Review Alert Evidence.”

Now, the case is no longer following a preset path. It has evolved based on real-time input. That’s CMMN flexibility in motion.

When Not to Use CMMN Sentries

Not every case needs dynamic logic. Some workflows are too routine, or the cost of modeling complexity outweighs benefits.

Use BPMN instead when:

• The process is highly standardized and repeatable.
• There are no unpredictable data triggers.
• Execution speed and predictability are more critical than adaptation.
• Multiple stakeholders expect a fixed, auditable path.

If your workflow is better described as “do this, then that,” BPMN is likely the right choice. CMMN sentries are not a substitute—they’re a tool for complexity.

Frequently Asked Questions

What is the difference between a CMMN sentry and a BPMN gateway?

Sentries control when an element becomes active. Gateways control the flow of execution between elements. A sentry decides whether a task can be started. A gateway decides which path to follow after a task completes.

Can CMMN sentries be triggered by external systems?

Absolutely. Event-based sentries can respond to messages from external systems—like a CRM update, an email, or a message queue. Integration with event-driven architectures (e.g., Kafka, RabbitMQ) is common in enterprise CMMN implementations.

How do I test CMMN sentry logic?

Use simulation tools in platforms like Visual Paradigm. Test multiple input scenarios: normal flow, edge cases, missing data, and event timing. Validate that sentries activate and deactivate as expected.

Are CMMN sentries the same as DMN decision tables?

No. While both use conditions, DMN decisions are for structured, rule-based choices. CMMN sentries are for controlling case plan element availability. They can be combined—e.g., a DMN table might feed input into a sentry condition.

Can I use CMMN flexibility in BPMN subprocesses?

Yes, but with limitations. BPMN doesn’t support event-based sentries natively. You can embed a CMMN case within a BPMN subprocess to bring in adaptive logic. This is a proven hybrid modeling pattern.

What happens if a sentry condition is never met?

The task or stage will remain inactive. It’s important to define timeout rules or escalation paths—otherwise the case may stall. Always include a fallback, such as a manual override or automatic re-evaluation after a set time.