Flowable CMMN stages and sentries

How Flowable CMMN stages and sentries model adaptive case work

Stages group case work, and sentries decide when that work becomes active or stops. In Flowable CMMN, a stage holds plan items such as human tasks, process tasks and nested stages, and each entry or exit sentry is a rule made of an if-part, which is a condition over case variables or events, and an on-part, which names the event that triggers the check. Together they let a case start work when something happens rather than when a previous step finishes. Flowable open source provides the CMMN engine under the Apache 2.0 license. It can be embedded as a JAR in a Java SE application, a servlet container or a Spring application, or driven over HTTP through the Flowable REST application. Teams should reach for this model when the path through the work depends on what people learn along the way, such as claims investigations, onboarding exceptions or credit reviews. A fixed, predictable sequence is usually clearer as a BPMN process.

The modeling decisions that matter most are which events a sentry listens to, what the if-part checks, and whether a violated or satisfied condition should end a stage or leave it running. Before building, sketch each stage's entry conditions and exit behavior on paper, then list the case variables and plan item events each condition needs. Ask whether a sentry can fire more than once and what happens if two sentries become true at the same moment, since both affect what the case does next. Confirm the exit types and sentry evaluation behavior against the Flowable CMMN documentation for the exact version you plan to run, because the engine's modeling details are where adaptive cases most often behave differently than the team expected. A short walkthrough with business owners of three or four realistic scenarios, run through the model, usually exposes gaps faster than reviewing the diagram alone.

Adaptive cases also need evidence that the right conditions drove each decision, which affects how you test and operate them. Plan test cases for each sentry in both its true and false states, and for the ordering of events that matter to the business. Record which variables and events a sentry evaluated, because an auditor or operations engineer will later ask why a stage opened or closed. Scope the cost of this work by counting stages, sentries and distinct event paths rather than diagram size, since each path adds test and review effort. When you request a quote from a partner, ask how they will test sentry behavior, how they will document the model for the business owners, and how changes to sentries will be versioned and tested before they reach a running case.

Which stage and sentry pattern fits which case

This table compares four ways to model stages and sentries in a Flowable CMMN case, with the business situation each suits and the testing effort it adds. Read each row as a choice between predictable ordering and adaptive behavior, and note that the testing cost grows with the number of sentry conditions and the events that can fire them.

Pattern	Best fit for	Testing cost to plan for
Sequential stage	Steps that must follow a fixed order, such as document collection before a review, where later work has no value until earlier work completes	Low: test the happy path and each step's failure or skip branch; few sentries to exercise
Parallel stage gated by an entry sentry	Work that can run together once a shared precondition is true, such as several checks that open after an intake form is validated	Medium: test the if-part on both sides of its condition and confirm that tasks inside the stage stay inactive until the sentry fires
Exit sentry that terminates optional work	Optional activities that become unnecessary when a decision is made, such as an extra verification task that ends when the applicant's risk rating is confirmed	Medium: test that the exit sentry terminates open plan items with the intended exit type, and that work already completed is left intact
Stage waiting on an on-part event	Cases that react to external facts, such as a payment notice or a counterparty reply, where the timing of the event is outside the case's control	High: test event ordering, events that arrive before the stage is active, and duplicate or late events
Combined sentries (if-part and on-part)	Adaptive cases where an event alone is not enough and business data must also meet a condition before work starts or stops	High: test each combination of event and variable state, and confirm the if-part is evaluated when the on-part fires

Setting up a Flowable case with stages and sentries

This sequence takes a case from a confirmed engine and starter setup to a deployed case definition whose stages open, close and complete based on sentries tied to real variables and events. Each step ends with a check so the team can see the case behave as designed before it reaches production.

Confirm the engine, starter and runtime
Before modeling anything, record which Flowable engine version, Java baseline and integration style the project uses. Confirm whether the CMMN engine runs embedded in a Spring Boot application through the CMMN starter, as a plain JAR in a servlet container, or behind the REST application. Check the supported database type and the Spring Boot line, because the 8.0.0 release moved to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3. Done when the team can name the version and the starter in its build file and a case deploys to a local database without errors.
Model stages from the business outcome
Work with case owners to list the outcomes the case must reach, such as an application verified or a claim ready for decision, and group the work needed to reach each outcome into stages. Keep stages to units a case worker would recognize, and place optional human tasks inside stages rather than at the top level. Avoid modeling a fixed order of steps at this point; the stages should describe what must be true, not when each task runs. Done when every stage maps to a named outcome and a reviewer from the business can explain each stage without reading the XML.
Define if-parts and on-parts from data and events
For each entry and exit sentry, write the if-part as a condition over case or stage variables, and the on-part as the standard events it reacts to, such as plan item transitions or milestones. Use only variables that the case creates or receives at start, and list each one with its type and where it is set. Keep conditions short enough that a tester can evaluate them by hand. Done when every sentry in the model lists its variables and events in a table that the developer and the business owner both signed off.
Add exit behavior and completion conditions
Decide which exit type applies to each plan item and stage, including whether an exit terminates active children, and set the required rules that decide whether a stage can complete. Check how a stage behaves when its entry sentry is satisfied after the stage has already ended, and whether repeated activation is intended. Record each decision next to the sentry it affects. Done when a written walkthrough explains, for every exit, what happens to running tasks and whether the case can still complete.
Deploy the case definition to a test environment
Package the CMMN file with the application and deploy it through the engine API or the deployment mechanism the project already uses. Confirm the deployment appears in the repository with the expected key and version, and that the application starts cleanly with the new definition. Record the deployed definition ID in the test notes so later tests can reference it. Done when the definition is listed as deployed in the test environment and a case instance can be created from it.
Verify with unit tests and case history
Write unit tests that start the case, set variables and fire events in controlled orders, then assert which plan items are active, completed or terminated. Include a test for each entry sentry, each exit type and one path where events arrive out of order. After the tests pass, inspect the case history for the test instances and confirm the recorded transitions match the expected sequence. Done when every sentry has at least one passing test and the history for a sample instance shows the transitions the design predicts.

Security and operational risks in adaptive case models

Adaptive case models react to variables, user actions and events, so the conditions that decide what happens next are also the places where data can leak, change unexpectedly or stall. The cards below cover the security and operational checks to make on Flowable CMMN stages and sentries before a case goes into production.

Sentry expressions reading sensitive variables

An if-part is an expression evaluated against case variables, so anything it reads becomes part of the case logic. Review which variables each sentry references, and keep personal or financial data out of expressions where a simple status flag will do. Confirm how the engine logs or exposes variables in history and REST responses, because a value used only for a decision can still be stored in case history. Treat expression content as reviewed code, not user input.

Sentries that mutate sensitive variables

Expressions in on-part handlers, listeners and task outputs can set variables as well as read them. A sentry that fires on an unexpected event can therefore change an approval status, a limit or a data field without anyone deciding to. List every place a case writes a variable, and confirm which of those writes are permitted to run automatically. Test with a case that receives events out of order, since that is where unintended writes tend to appear.

Unauthorized human task completion

When a sentry waits for a user to complete a human task, the engine checks who can act on the task only as far as your application configures it. A plan item that completes on a manager's action may be completable by anyone with access to the case unless you add checks. Define which roles or identities may complete each task that feeds a sentry, and verify those rules through the REST endpoints as well as the UI. The engine's authorization is your responsibility to design.

Identity source for case actors

Flowable's identity management can be replaced with a custom implementation, and an LDAP reference implementation is provided. Whichever identity service you use decides who counts as a candidate for a human task that drives a sentry. Confirm that group membership is current when tasks are assigned, and that removed or transferred users no longer hold tasks that unlock case progress. Document the source of truth for each role used in sentry conditions.

Monitoring case state in production

A case that is waiting on a sentry can look healthy while it never progresses, so case state needs its own monitoring. The Spring Boot starters expose an actuator endpoint at /actuator/flowable for monitoring running processes, which is a starting point for dashboards and alerts. Decide which states count as stuck, such as a case waiting on a human task beyond an agreed period, and alert on those rather than on engine errors alone.

Recovering from failed jobs

Timers and asynchronous jobs, including those that evaluate or re-evaluate sentries, run on the async executor. The executor coordinates nodes through lock owners and lock expiration times in the database, so expired locks are recovered and jobs are picked up by another node. Even so, a job that fails repeatedly needs an owner. Plan how failed jobs are found, retried and reported, and rehearse recovery for a case whose sentry depends on a timer that did not fire.

Limits to confirm before you commit to a sentry design

Sentry behavior, database support and the surrounding runtime all depend on the exact Flowable release and setup you run. The cards below list what to confirm in your environment before you write sentry logic that your case depends on.

Flowable version and release line

Sentry semantics are part of the CMMN engine, so confirm the exact version and release line you plan to run and whether your model conventions match it. Flowable 8.0.0 was released on February 27, 2026, following 7.2.0 on August 21, 2025 and 7.1.0 on October 7, 2024. Ask the vendor or check the release notes for any change to if-part or on-part handling between the line you target and the one you upgrade to later. Record the version in the case model documentation so reviewers test against the right behavior.

Supported database types

Sentries evaluate against case and plan item state that the engine persists, so the database you choose affects how the runtime behaves under load and during recovery. The configuration docs list H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server. Confirm which of these your standards allow, and check the MySQL version floor, since versions below 5.6.4 lack millisecond precision. Timestamp precision matters when sentries order events that occur close together.

Spring Boot baseline when embedded

If you embed the engines in a Spring application, the Spring Boot generation sets the Flowable line you can use. Flowable 8.0.0 moved to Spring Framework 7 and Spring Boot 4 and dropped support for Spring Boot 3, so an application still on Spring Boot 3 cannot take that release without an upgrade first. Confirm your baseline, the starter you need for the CMMN engine, and the JSON library your application uses, since the default changed to Jackson 3 in that release.

Sentry behavior in your chosen version

Do not assume sentry evaluation order, duplicate event handling or re-evaluation timing from older examples. Build a small reference case in your target version that covers an if-part that becomes true before the on-part fires, a standard event arriving twice, and an exit sentry that fires while a child task runs. Keep the results as a regression baseline. Where the docs leave a behavior unclear, record the question and ask the vendor before the design depends on it.

Identity and access interaction

Sentry conditions often read case variables that reflect who acted, such as an approver or a role. Flowable lets you replace identity management through the IdmIdentityService interface, so the identity data a sentry sees depends on your implementation. Confirm how group and role data reaches the engine, whether a user action that satisfies a sentry is authorized by your application, and who may change variables that gate an exit. The engine does not make those authorization decisions for you.

Async executor and multi-node behavior

Timers and asynchronous jobs that feed a sentry run on the async executor, which coordinates nodes through lock owners and lock expiration times in the database. Confirm how many nodes will run the engine, how expired locks recover after a crash, and whether a timer-driven sentry can fire late or twice under your topology. Test sentry timing with two nodes before you rely on it in production.

Questions teams ask before building adaptive cases

What drives the cost of building a Flowable CMMN case with stages and sentries?

The main drivers are how many stages, plan items and sentries the case has, how many of those sentries depend on external events, and how much test coverage the case needs before it goes live. Each sentry adds a condition path that must be modeled, exercised and explained to the business. Costs have two parts: the design and build effort, which is usually a one-time cost, and the ongoing maintenance of the case model as business rules change, which recurs. Ask any partner for a quote that breaks out modeling depth, the number of events and listeners, and the test plan, so you can see which items move the price when scope changes.

How long does a Flowable case with stages and sentries take to build?

Duration depends mainly on case complexity: the number of stages, the number of entry and exit sentries that combine if-parts and on-parts, the external systems that raise events, and the number of business outcomes the case must handle. A case with a few stages and internal triggers is much shorter to model than one that reacts to several integrations and needs many exit paths tested. No duration figure is supplied for this topic, so ask for a timeline tied to a written scope, and check that it includes review with domain experts and testing against realistic case paths.

Can our internal team build adaptive cases without outside help?

Yes, if the team already knows Java and Spring, has run Flowable or a similar engine, and has someone who can translate business policy into sentry conditions. Flowable is open source under Apache 2.0, and its docs describe the CMMN engine and its embedding options. The harder part is usually not the XML but the modeling discipline: deciding which events a case should react to, what counts as completion, and how exit paths are tested. Teams without that experience often benefit from a short design review or a scoped build with a partner, while keeping ownership of the model afterward.

What do we need to provide for a stages and sentries engagement?

Expect to provide three things. First, domain experts who can describe real case paths, including the unusual ones, and confirm which outcomes count as success. Second, access to the target environment, such as a test Flowable deployment, the systems that raise events, and the database the engine will use, so the model can be run and tested where it will live. Third, an agreed scope in writing that lists the case definitions, the events in scope and the tests to be delivered. Most delays come from late access or unclear completion rules.

How do sentries get evaluated, and what breaks when they are misconfigured?

Engineers should confirm the exact evaluation behavior against the Flowable CMMN documentation for the version they run. In general, entry sentries decide when a plan item can start, and exit sentries decide when it should be terminated, so an if-part that depends on variables and an on-part that waits for an event must be designed together. Common failures include conditions that never become true, exit conditions that fire too early, and variables that are not set when the condition is checked. Tests should cover each path, including events that arrive out of order.

Should we use BPMN instead of CMMN for this process?

Choose BPMN when the sequence is predictable, every step is known in advance and the main concern is routing work and enforcing order. Choose CMMN when the work is knowledge-driven and the next step depends on what has happened, such as investigations, claims or case handling with many optional tasks. Many applications combine both: a case can call a BPMN process for a fixed sub-flow. Ask a partner to test your three most common paths in both models before committing, because the modeling and testing cost of each choice differs.

Does the case model need security or compliance review before go-live?

Yes, if the case handles regulated data or decisions that auditors will test. Sentries often gate sensitive actions, so the conditions and who can trigger events should be documented, and the engine's history should show why a stage started or ended. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or certification. Confirm early which control requirements apply to your case, and agree with your assessor what evidence the case history must provide.

What version changes mean for existing case models

Version changes in Flowable affect case models less through the CMMN syntax than through the platform underneath them. Flowable 8.0.0, released on February 27, 2026, moved to Spring Framework 7 and Spring Boot 4 and does not keep backward compatibility for Spring Boot 3, according to the Flowable 8.0.0 release notes. Version 7 had already moved the engines to Java 17, Spring Boot 3 and Jakarta EE, as described in the Flowable 7.0.0 release notes. If your cases run inside an application that carries any of these older baselines, the stage and sentry definitions are only one part of what changes.

Re-test every case model on the target version before you upgrade. Sentries, plan item rules and event listeners depend on expression evaluation and on the variables you pass in, and the surrounding framework can change how those expressions and the JSON or Spring beans behind them are resolved. Build a regression set that starts a case, drives it through an entry sentry, an exit sentry and a stage completion, and checks the resulting plan item states and history. Run it against a copy of your production case definitions and a copy of the database, and keep the expected results with the model in version control.

Confirm with your own engineering team which Java, Spring and Jakarta dependencies your case delegates and custom expression beans rely on, since those are the parts most likely to break silently. For the full upgrade path, including the order of framework and engine changes, read the Flowable upgrades topic in this group, which covers the major version changes in detail.

How DeployOpen scopes case modeling work

Case modeling work on Flowable CMMN is scoped before any model is drawn. DeployOpen works on a fixed-scope basis: the scope, the deliverables and the timeline are agreed in writing before work starts, and a quote follows from that written scope. For a stages and sentries engagement, the scope should name the cases in question, the stages and plan items each case contains, the entry and exit sentries that govern them, the human tasks and case variables the model depends on, and the integrations with processes, decisions or external systems that the case calls. A scope that lists only the case names will leave the sentry logic and the test cases undefined, and those are where most of the effort sits.

Expect the written scope to ask for specific decisions from your side. Name the business owner who can confirm which milestones and events count as progress, the people who will test the adaptive behavior against real case histories, and the environment where the model will run. Ask whether the scope covers only the case model, or also the Java delegates, REST calls and test suites that exercise it. Confirm which Flowable engine version the project targets, since the Flowable open source page describes the engines the work builds on, and the release history in the flowable-engine repository shows how often versions change. A quote that lists these items explicitly is easier to compare with your own team's estimate.

DeployOpen does not publish a price list, so there is no standard rate to compare against. Ask each partner to break the quote into the scope items above, and to state which items are one-time (initial modeling, sentry design, testing and handover) and which recur (support, model changes and engine upgrades). Ongoing support, upgrades and continuous testing are available as a retainer, which suits teams that expect their case definitions to change after go-live. Ask what the retainer covers, how change requests are priced against it, and what happens when a case definition must be migrated to a new version.

How DeployOpen delivers Flowable case work

DeployOpen plans, implements, tests, documents and supports Flowable CMMN case models in infrastructure you control, with the stage and sentry design agreed in writing before the build starts. The work runs on the same open-source engines that Flowable publishes under Apache 2.0, so your team keeps full ownership of the model, the code and the deployment.

How we scope

Written scope lists the case definitions, stages, entry and exit sentries and human tasks covered by the engagement.
Discovery maps which business outcomes must hold before a stage can close, and which events can happen in any order.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
Ask for the list of sentries, exit types and listeners the quote covers, so you can compare partner proposals line by line.

How we build

Stage and sentry models are drafted in CMMN and reviewed with process owners before any Java delegates or listeners are written.
If-parts and on-parts are checked against the variables and events each case actually receives at runtime.
Each case definition gets unit tests that drive plan items through every sentry path, including exit and early termination cases.
Integrations with BPMN processes and DMN decisions are built and tested against the same case variables your team will use in production.

How we hand over

Handover includes the CMMN models, Java code, deployment steps and a written record of each sentry's condition and exit type.
Documentation explains when sentries are evaluated, so operators can interpret case history when a stage did not complete as expected.
Your engineers pair on test runs and the deployment pipeline, so they can change sentries and redeploy definitions without us.
Acceptance criteria are checked against the written scope, with open items recorded and assigned before the engagement closes.

How we support

Ongoing support covers fixes, Flowable version upgrades and changes to case models, available as a retainer.
Upgrades are planned against the Flowable release notes, including changes to the Java, Spring and Jakarta baseline.
Continuous testing of case paths can be added to a retainer so that sentry changes are checked before release.
Confirm with DeployOpen which support hours, response expectations and escalation paths the retainer includes before you sign.