When to use Flowable CMMN instead of BPMN

When to use Flowable CMMN instead of BPMN for your application

Use CMMN for adaptive knowledge work and BPMN for predictable sequences. If the steps of a case depend on what people find as they work, such as an insurance claim that may need investigation, specialist review or a change of direction, model it as a Flowable CMMN case. If the path is known in advance and the question is mainly ordering, routing and handoffs, such as an approval chain with fixed stages, model it as a Flowable BPMN process. Most applications need one of these as their core, and the decision shapes your modeling effort, testing scope and the people who will maintain the models for years. The Flowable open source page describes three engines in one family. The BPMN engine executes process models, the CMMN engine manages cases, and the DMN engine evaluates decision rules. All three are licensed under Apache 2.0, and each exposes both Java and REST APIs, so a team can embed the engines in a Spring or servlet application or call them over HTTP. Because the engines share this foundation, the choice is not about platform. It is about which model fits the work, and whether the two should be combined. Before committing, confirm with your Flowable contact which engine version and deployment style you will use, since the Java and Spring baseline differs between major releases. In practice, many applications use both. A case can start a process for a fixed sub-sequence, call a decision table, or spawn a child case, and the sibling topics on calling BPMN processes and child cases cover those mechanics. Your decision should therefore be made per piece of work, not per application. Ask three questions: can you list the steps in order before the work starts, does the sequence change based on conditions that only appear at runtime, and who will edit the model when the business changes it. Write down the answers for each workflow, and have a developer and a business analyst test a sample of each model against real cases before you build the rest of the application.

Decision criteria: sequence, variability and who decides the next step

Each test asks a different question about the work: whether the order is fixed, who decides the next move, whether steps are optional or repeat, and what signals progress. Answer them for one business process at a time, using the people who run that work rather than the flowchart someone drew first.

Is the order of steps fixed?

Where every instance passes through the same steps in the same order, BPMN gives a direct model of the flow, with gateways for the branches that matter. Where the next step depends on what has been learned so far, a fixed sequence forces a flow that no one actually follows. Walk ten real examples from start to finish and count how many paths you see. If most instances take a different route, the model is probably a case.

How much depends on judgment?

Some work is routing and approval against written rules, which suits a process with decision tasks. Other work depends on a professional weighing documents, exceptions and context, and the next action is their call. In that case the case model can keep the human decision visible while the engine tracks what is open. Ask who would be blamed if the system chose the next step and got it wrong.

Are tasks optional or repeatable?

Some activities happen only when a condition arises, and some happen once per item in a list, such as each document or each claimant. Modeling these as optional or repeated work in a case keeps the model readable, but it also needs limits so the number of open items stays bounded. Check whether the business can state a maximum for each repeated activity. If it cannot, the design needs more work before any engine is chosen.

Is progress measured by milestones?

If the business reports progress as reached points such as verified identity, approved limit or regulator notified, the work is organized around outcomes rather than steps. Milestones and sentries in a case map to those outcomes directly. A BPMN process can show progress through its path, but the status meaning may need to be derived. Confirm the milestone names with the people who report status today.

Who owns the next step?

Count the roles that can move work forward and note whether they act on the same item at the same time. A case lets several people work on open items under shared rules, while a process usually assigns each task to one owner in turn. Ownership also affects authorization design, because the engine leaves access checks to the application. Map who can start, complete and reopen each activity before choosing the model.

Which model fits which kind of work

Approval chains, handoffs and intake routing have a known order of steps, a clear owner for each step, and a small number of exit paths. BPMN fits this work because the process model is the contract: the diagram shows the sequence, gateways show the decisions, and the engine executes exactly what is drawn. Reviewers can trace a path from start to end, and tests can assert each branch. The same clarity makes change control easier, since a new approval level is a visible edit to one diagram.

Fixed sequence: Each step follows the one before it, and the diagram matches what people do.
Explicit branching: Exclusive and parallel gateways express the decisions the business has already made.
Simple audit trail: Process history shows which path each instance took and who acted on each task.
Lower modeling cost: A process with a few dozen tasks is usually faster to model, review and test than an equivalent case.
Clear ownership of change: A new step is a single edit to a single model, with a deployment record behind it.

Illustrative example: a purchase request that routes to a manager, then to finance above a threshold, then to a buyer. Confirm with your process owners that the steps and exits are stable enough to draw once.

How BPMN processes and CMMN cases work together in one application

A Flowable case can hand work to a BPMN process through a process task, to a child case through a case task, and to a DMN decision through a decision task. Use these task types when one part of a business capability follows a fixed sequence and another part needs to be driven by the case worker's judgment. For example, in an illustrative claims application, the case might hold the investigation as a flexible stage while a process task runs a standard payment approval that always follows the same steps. Before you commit to this split, confirm in the current Flowable CMMN documentation exactly which task types exist in your engine version, how each one is modeled, and what the case does when the called definition fails or is not deployed.

Variables are the main coupling point between the two models. The case passes values into the called process or child case through the task's input mappings and receives results back through output mappings, so the contract between them lives in the model rather than in code. Decide early which variables cross the boundary, give them stable names, and document their types, because a renamed or retyped variable breaks the call at runtime rather than at deployment. Plan a test that starts the case, runs the called definition, and checks the returned values, since mapping errors are easy to miss when each model looks correct on its own.

The choice between blocking and non-blocking behavior determines whether the case waits for the called work before it moves on. A blocking task keeps the calling plan item active until the called instance completes, which suits steps where the next case decision depends on the result. A non-blocking task lets the case continue while the called work runs, which suits parallel work such as notifications or background checks, but it leaves you to track the outcome and handle late failures. Confirm the exact blocking semantics for each task type against the current CMMN documentation, then write down the expected behavior for each call so that operations staff and testers can verify it.

Modeling and testing cost of each choice

This table compares a BPMN process, a CMMN case and a hybrid of both across modeling effort, testing focus, runtime visibility, team skills and the cost of change. Read each row as a driver of effort, not a fixed price, and use the last row to decide which trade-offs your team can carry.

Factor	BPMN process	CMMN case	Hybrid (BPMN and CMMN)
Modeling effort	Sequence, gateways and events map directly to a known path, so the model is usually shorter to draw and review	Stages, plan items, sentries and rules take more design time up front to capture all the valid orders of work	Effort adds up across both models, plus the interfaces that connect them
Testing focus	Test the paths through the flow and the handling of errors, timers and boundary events	Test sentry conditions, rule combinations and the states a case can reach, which grows with the number of plan items	Test each model alone, then the call points between them, including variables passed in each direction
Runtime visibility	Users see a clear position in the sequence and a predictable next step	Users see which plan items are available, active or complete, which suits work with no fixed order but needs clear status reporting	Visibility depends on which model owns the status shown to users, so define that ownership early
Team skills needed	Analysts and developers familiar with BPMN 2.0 and gateway logic can contribute quickly	Modelers need to think in terms of conditions and events, and business experts must review sentries with developers	Both skill sets are needed, and the team must agree on when each model is the right tool
Effect of changing requirements	Adding a step usually means editing the sequence and checking the paths around it	Adding a case option may affect sentries and rules across the stage, so changes need wider regression testing	Changes stay contained if each model has a clear boundary, but a change that crosses the boundary touches both
What to confirm with your team	Whether the work has a stable, documented order that auditors and operators expect to see	Whether the work truly varies by case, and who will maintain the sentry and rule logic after go-live	Who owns the boundary contract, how case status feeds process decisions, and who signs off on each change

How to choose and prototype the model before build

This sequence turns a vague question about process versus case into a tested decision, with a deployed prototype of each model that the team can read and test before any build budget is committed. Each step closes with a check so the decision rests on evidence rather than preference.

List the work as outcomes
Start by writing down the outcomes the application must produce, such as an approved loan, a closed incident or a completed onboarding, rather than the screens or tasks people use today. Domain experts and the people who do the work should draft this list together, with a product owner signing off. Done means every outcome has a plain-language definition, an owner and a list of the inputs that can change the path to it. This list is the input for every later step, so keep it short enough that a non-engineer can review it in one sitting.
Classify each step by predictability
For each outcome, break the work into steps and label each one as predictable (the order is fixed and the same every time), conditional (the order depends on data, such as a value threshold) or open-ended (the next action depends on what a person discovers). Ask the operations lead which steps they have had to improvise, skip or reopen in the last year, since those usually mark the knowledge work. The check is a table where every step has a label and each open-ended step has a short note on what information would decide the next action. Predictable and conditional steps lean toward BPMN, while open-ended work leans toward CMMN.
Prototype one case and one process
Model one outcome from the list as a BPMN process and another, with more open-ended work, as a CMMN case, both running in a Flowable engine that matches your target Java and Spring baseline. Keep the models small and executable, with a few tasks, one decision and one human step, and deploy them to a local or test database such as H2 before using your production database type. The check is that both definitions deploy without errors, that you can start an instance of each, and that the running plan items or tasks match what the domain experts described. If the case model cannot express the work without workarounds, record that as evidence.
Check how the team reads each model
Show the two prototypes to the business analysts, the developers and the operations staff who will support them, and ask each group to explain in their own words what happens next after a given event. Record where the readers disagree, where a diagram hides a rule, and which notation fits the way people already describe the work. The check is a short review note per model that lists the questions readers could answer without help and the ones they could not. A model that only its author can read will cost more to change and to support later.
Decide on the combined design
Most applications contain both kinds of work, so decide where the boundary sits: which case owns the overall outcome, which predictable steps should run as a BPMN process called from a case task, and which decisions should move into DMN tables. Use the prototypes to test one call in each direction, confirming that variables pass as expected and that a blocking call does not stall the case. The check is a written boundary diagram that names the owner of each stage and the variables that cross it. Keeping this boundary explicit prevents two engines from holding partial copies of the same state.
Agree the testing approach for each model
Decide how each model will be verified before build starts, and assign an owner to each test type. Predictable BPMN paths are usually covered with process-level unit tests that drive the engine with fixed variables, while CMMN cases need tests that send events, complete plan items and assert the case state after each event, because the same inputs can produce different paths. Include a test for every boundary call and one end-to-end run on the agreed database type. The check is a test plan listing each path, the tool that runs it, and the team that maintains it. Confirm the exact test libraries and versions with your Flowable release notes and your build tooling.
Record the decision and its evidence
Write a short decision record that states which outcomes are modeled as BPMN, which as CMMN, and which parts are combined, along with the prototype results, reader review notes and test plan that support the choice. Note the Flowable version and the database type used in the prototype, since later upgrades can change engine behavior, and list the questions still open for the build, such as licensing, support needs or integration constraints. The check is that a reviewer outside the project can read the record and reach the same model choice from the evidence alone. Ask a partner or internal architect to review it before the build backlog is written.

Security and operational considerations for mixed case and process applications

A mixed application runs BPMN processes and CMMN cases on the same engine, database and identity layer, so the same controls apply to both. The cards below cover the checks that carry across both models: who can act on work items, what gets recorded, how jobs run across nodes, and where identity comes from.

Authorization stays with your application

The engine tracks who owns and who can act on tasks, but the REST and Java APIs for cases and processes do not enforce your business rules on their own. Case plan items, human tasks and process tasks all need checks in your application or gateway so that a user can only start, complete or reassign work they are allowed to handle. Review each endpoint that lists or completes plan items and tasks, and test it with users from different roles.

History and audit trail design

Both process instances and case instances write history, but the level of detail and retention you configure decides what an auditor or incident responder can reconstruct. Decide which events, variables and task changes must be kept for each model, and confirm the history level in your configuration before go-live. Store the history in the same supported database you run in production, and test that you can answer a question such as who completed a case task and when.

Async executor across nodes

Timers and asynchronous jobs in both processes and cases run through the async executor, which uses a thread pool on each node. Nodes coordinate through lock owners and lock expiration times stored in the database, so a job locked by a failed node is picked up by another node after its lock expires. Confirm the lock settings for your environment, and test a node failure during a case timer, because a delayed or duplicated firing is the usual symptom of a misconfigured cluster.

Identity service replacement

Flowable ships with its own identity management, which is intended to be replaced by your directory. The docs describe overriding the IdmIdentityServiceImpl class or implementing the IdmIdentityService interface, with an LDAP identity service provided as a reference. Candidate owners, groups and assignees used by process tasks and case human tasks must resolve through that service, so decide on the identity source before modeling candidate groups.

Database and configuration choices

Both models depend on the same database schema, so the database type and version you choose affect every engine feature in the application. The configuration docs list H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server as supported types and note that MySQL versions below 5.6.4 lack millisecond precision, which matters for timer ordering. Check the database list and your version against the configuration docs before the case and process models share a production schema.

Questions teams ask before choosing CMMN or BPMN

Can one model replace the other in a Flowable application?

Usually not cleanly. BPMN models a flow that is known in advance, with explicit sequence flows, gateways and tasks that run in a defined order. CMMN models a case, where work items become available when conditions are met and people decide what to do next. You can rebuild a case as a process, but the diagram then encodes every path someone expected, and every new path needs a model change. The practical question is which model matches how the work is actually decided, then how the two connect. Flowable supports calling processes from cases and cases from processes, so most applications use both rather than forcing one model to do everything.

What modeling and testing effort does each choice add?

Effort is driven by how many paths the business must control. A BPMN process with a stable sequence, a few gateways and clear exception handling is usually the smaller model to build and test, because each path can be traced in a diagram. A CMMN case adds effort in sentries, plan item rules and event listeners, and tests must cover the order in which conditions become true, not only the happy path. Ask your team to list the business states, the events that move work forward and the scenarios that must never happen. Those lists drive the test matrix more than the diagram size does.

What do business analysts and developers need to provide?

Business analysts must describe the work as states, milestones and conditions, not only as steps. They need to name the decisions, the people who make them and the evidence required before a stage can close. Developers need to implement delegates, listeners, variables and the integration points, and they need test coverage for repeated or optional work. For BPMN, analysts typically map a sequence and exceptions. For CMMN, they also need to agree on which items are required, which are optional and what counts as completion. Plan a joint modeling workshop before the build starts, because gaps in these definitions are the most expensive to fix later.

Can our internal team decide between CMMN and BPMN without outside help?

Yes, many teams can, provided they test the choice against real cases. Start with a few representative scenarios from operations, including the ones that are rare but costly. Model each scenario in both notations and count how many branches each diagram needs and how many changes you expect in the next year. If the process rarely changes and the paths are fixed, BPMN is usually the better fit. If experienced staff routinely reorder work, skip steps or add tasks on the fly, CMMN is worth considering. A partner can be useful as a second opinion on the model, the testing approach and the Flowable features that matter for your environment, and the scope of that review should be agreed in writing before work starts.

How does the choice affect later changes and version upgrades?

It shapes how much change costs after go-live. A BPMN model changes by editing the flow, and running instances keep working only if the version mapping is planned. A CMMN case changes through plan item definitions, so changes to sentries or repetition rules can affect running cases, and migration of running case instances needs explicit planning with plan item mappings and validation. Check the Flowable 8.0.0 release notes before planning an upgrade, because that release moved the baseline to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3. Those platform changes apply regardless of which notation you choose.

Do the two notations need separate runtime infrastructure?

No. Flowable's BPMN, CMMN and DMN engines are compact Java engines that can run in the same application and share the database and APIs, so one deployment can host processes, cases and decisions. The runtime cost difference is smaller than the modeling cost difference. What matters more is how the engines are sized and how jobs and history grow. Confirm the supported databases for your environment in the Flowable configuration documentation, and confirm the Spring Boot starters and actuator endpoints if you run on Spring Boot.

Does Flowable open source include support for either notation?

Flowable open source is licensed under Apache 2.0 and includes the BPMN, CMMN and DMN engines with Java and REST APIs. Open source users get a community forum. Professional services and partner support are offered separately, and the commercial products add low-code modeling and visual debugging. If your team needs vendor-backed support for production cases, ask Flowable which support options apply to your version and deployment before you commit to a notation.

How DeployOpen scopes case and process design with your team

Deciding between a CMMN case and a BPMN process is easier to settle with a written scope in hand, because the choice changes the modeling work, the test plan and who on your side must sign off on the rules. DeployOpen plans and implements Flowable engines inside your own infrastructure, including your cloud accounts, data centers or air-gapped networks, so the models, the database and the running engine stay under your control. Most engagements are fixed-scope, which means the agreement names the process and case models in scope, the decision tables that will be called, the integrations and the acceptance tests before any modeling starts.

A useful scoping conversation for this decision covers four items: which work is predictable enough for BPMN sequences, which work depends on knowledge workers choosing the next step and therefore needs CMMN stages, sentries and milestones, where the two hand off to each other through process tasks and case tasks, and how the team will test each style. Ask for a written list of the case definitions, process definitions and DMN decision tables that will exist at the end of the work, along with the owners of each rule. Confirm which Flowable version and database the scope targets, since the supported versions and database types are documented by Flowable and can differ between releases.

Once the scope is agreed, DeployOpen quotes follow from that written scope rather than from a published price list, so the quote will show who builds each model, who writes the tests and what is handed over. Ongoing support, version upgrades and continuous testing are available as retainers, which suits teams that expect the case models to change as business rules evolve. Ask for the quote to separate one-time modeling and testing effort from any recurring support, and to state the assumptions about your environment that would move the estimate.

When to use Flowable CMMN instead of BPMN