Using Sentries for Event-Driven Control

Estimated reading: 7 minutes 8 views

Many modelers assume that CMMN is simply about making tasks appear when certain conditions are met—like a checklist with automated triggers. But that’s a misunderstanding of what a CMMN sentry truly does.

A sentry isn’t just a gatekeeper—it’s a live listener, constantly evaluating the current state of a case. It responds to changes in data, events, or external systems in real time, ensuring that your case model adapts to reality, not a rigid timeline.

With over two decades of modeling complex, unstructured processes—especially in healthcare, insurance, and compliance—I’ve learned that the real power of CMMN lies not in sequence, but in responsiveness.

What you’ll gain here is a clear, actionable framework for designing sentry conditions that reflect real business behavior. You’ll learn how to set up dynamic entry and exit criteria, avoid common modeling traps, and use event-driven control CMMN to handle unpredictable workflows with precision.

Understanding the Role of CMMN Sentry

At its core, a CMMN sentry is a condition that determines when a task or stage becomes available. It’s not a static rule—it’s a logic expression evaluated in context, based on the current state of the case.

Unlike BPMN gateways, which evaluate once and move on, CMMN sentries re-evaluate every time a relevant event occurs. This means a task can become active not only at start-up but also after a document upload, a status change, or even a new notification.

Think of a sentry as a security guard who doesn’t just check ID at the door—he keeps an eye on the building, responds to alarms, and reacts to emergency signals in real time.

How CMMN Sentry Differs from BPMN Gateway

It’s easy to confuse the two, but they serve fundamentally different purposes.

BPMN gateways control flow in predefined, linear processes. They decide the next step based on a condition after a task completes.
CMMN sentries control task availability based on events or data states, regardless of task order.
BPMN is about structured control flow; CMMN is about adaptive awareness.

When modeling a medical intake case, for example, a sentry can trigger a “Review by Specialist” task the moment a lab result arrives—not after a fixed delay or after another task finishes.

Designing Effective CMMN Entry Criteria

The first step in using sentry conditions is defining clear entry criteria. These are the conditions that, when met, allow a task to be activated.

But here’s where many modelers go wrong: they use overly complex conditions that are hard to test, validate, or maintain.

Start simple. Ask: “What event or data state makes this task relevant?”

Best Practices for CMMN Entry Criteria

Use specific data references—e.g., “when claim.status equals ‘pending_review'”.
Avoid temporal triggers unless absolutely necessary. Instead of “after 48 hours”, use “when claim.submitted_date + 48h > now()”.
Limit condition complexity. If you need more than three conditions, consider splitting into multiple sentries.
Document the intent—add a comment explaining why this task should activate under these conditions.

Remember: clarity in condition logic means fewer bugs, easier audits, and better stakeholder buy-in.

Implementing Event-Driven Control in CMMN

Event-driven control CMMN means your case model doesn’t wait for a sequence to unfold. It reacts.

Real-world case work is rarely linear. A customer support case might jump from “escalation” straight to “resolution” if a supervisor issues a directive. A claim might trigger a fraud check the moment a suspicious transaction is flagged.

That’s where sentry conditions shine. They’re not just about “if this, then that”—they’re about responsiveness.

Common Event Triggers for CMMN Sentry

Trigger Type	Example Condition	Use Case
Data Change	`document.status = 'approved'`	Activate review task after document approval
Time-Based	`now() > claim.submitted_date + 72h`	Trigger escalation after 72 hours of inactivity
External Event	`external_alert = 'fraud_detected'`	Flag case for fraud review upon external alert
Status Change	`claim.status = 'under_review' AND claim.reviewer = 'expert'`	Activate expert review when case reaches assigned reviewer

These aren’t just theoretical. I’ve seen models where a sentry condition on a claim status update triggered a full compliance audit only when a risk score exceeded threshold. That’s event-driven control CMMN in action.

Modeling Sentries: A Real-World Example

Let’s walk through a scenario from the insurance domain: a claim that requires verification after a car accident.

Here’s how you would model it using sentry conditions:

Stage: “Document Verification”
Task: “Verify Insurance Policy”
Entry Condition: claim.verification_required = true AND policy_file.status = 'uploaded'
Exit Condition: policy_file.status = 'verified'

When the policy file is uploaded, the sentry evaluates. If the claim is flagged for verification, the task becomes active. Once verified, the case progresses.

What makes this powerful? The task never auto-activates. It only appears when the data says it should.

Pro Tip: Avoid Logic That Blocks Progress

Don’t set sentry conditions that assume all data will be available. For example:

if (claim.driver_age > 25 AND claim.claim_amount < 5000)

If either field is missing, the condition evaluates to false—and the task stays hidden. That’s a risk.

Instead, use:

if (claim.driver_age > 25 OR claim.claim_amount < 5000) AND claim.status = 'pending'

Or, even better, use a conditional evaluation that handles missing data explicitly.

Common Pitfalls and How to Avoid Them

Even experienced modelers fall into traps when using sentry conditions. Here are the top five:

Over-reliance on time-based conditions → They’re brittle. A system delay or time zone mismatch can break them.
Using sentries to enforce sequence → That’s BPMN’s role. CMMN is about flexibility, not control flow.
Complex logic with no comments → Others (and future you) won’t understand it.
Not testing edge cases → What happens if a value is null? If data is missing?
Using global variables without context → It’s hard to debug when the source of truth isn’t clear.

Always ask: “Can this condition be triggered by an external event? Or is it just a fake deadline?”

Frequently Asked Questions

What is a CMMN sentry used for?

A CMMN sentry controls task or stage availability based on real-time business conditions. It enables event-driven control CMMN by reacting to data changes, system events, or time-based triggers.

How do I write a proper CMMN entry criteria?

Start with a clear business rule—e.g., “Activate the review task when a document is approved.” Then translate it into a condition using case data. Keep it simple, testable, and well-documented.

Can sentry conditions be evaluated after task completion?

No. Sentry conditions are evaluated before a task becomes available. Once a task is active, sentry conditions don’t re-evaluate unless an event triggers a refresh. Use exit criteria to control task completion.

What’s the difference between a sentry and a milestone?

A sentry determines when a task becomes available. A milestone marks a significant point in the case lifecycle—like “claim approved” or “case closed.” Milestones are often reached after a sentry condition is met.

Why isn’t my task activating even though the condition seems true?

Check if the data is updated in real time. Some systems delay data propagation. Also, verify that the condition uses correct variable names and handles null values. Use debug logs or simulation to trace evaluation.

How do I handle multiple sentry conditions on one task?

Use logical AND/OR operators. But avoid mixing too many conditions. If you have complex logic, split the task into sub-tasks or use nested stages. This improves readability and maintainability.