How Flowable CMMN process tasks call BPMN processes and child cases
A case team that needs a predictable sequence inside knowledge work can have a Flowable CMMN plan item start a BPMN process, open a child case, or evaluate a DMN decision, instead of modeling every step as case work. The short answer is that process tasks, case tasks and decision tasks are the plan item types that make these calls, and each one decides whether the parent case waits for the called element to finish. Before building, the team should settle which work is sequential and auditable enough to belong in a process, which is adaptive enough to stay in a case, and which is a rule that a decision table should own.
The Flowable open source engines cover all three notations. The BPMN engine executes process models, the CMMN engine executes case models, and the DMN engine evaluates decision rules. According to the Flowable open source page, they are compact Java engines with Java and REST APIs, licensed under Apache 2.0. They can be embedded in Spring applications, servlet containers or Java SE applications, or used over HTTP through the Flowable REST application, according to the Flowable getting started guide. Combining them in one application makes sense when a case has a fixed approval or data-validation sequence that auditors expect to see as a process, or when one decision is reused by several cases. It makes less sense when the whole flow is a single short sequence that a BPMN process alone can express.
Before designing the calls, confirm three things with your Flowable engineers: which engine version and Spring baseline you run, since the Flowable 8.0.0 release notes describe a move to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3, and whether your application's variable mapping and input and output rules match the behavior of the version you deploy. Then decide, for each called element, whether the parent case should wait for its result. That blocking choice drives the case's completion rules, error handling and how users see progress, and it is the decision most likely to need rework later if it is made by default.
Process task, case task or decision task: which call fits
A process task starts a BPMN process from inside a case plan item. It suits work that has a fixed, ordered sequence of steps, such as a document check that always runs the same way, while the case around it stays flexible. The case hands over the work and tracks the process instance it created. What the case waits for depends on how the process task is configured, so confirm the blocking behavior in the Flowable CMMN documentation before you rely on it. What comes back is the process outcome, exposed to the case through variables you map.
- What it fits: (illustrative) an onboarding case where identity verification is a fixed BPMN sequence inside a larger adaptive case.
- What the case waits for: confirm whether the plan item completes when the process completes or as soon as it starts.
- What returns: process variables you choose to copy back to case variables.
- Ownership: the process has its own definition, versioning and history.
- Check: how the process instance is linked to the case plan item in your version.
Confirm these specifics against the Flowable CMMN and BPMN docs for your release before modeling.
A case task starts a child case from a parent case. It suits work that is itself open-ended, with its own stages, sentries and human decisions, and that should be reused across several parent cases. The parent treats the child as one unit of work, while the child manages its own plan items. Whether the parent waits for the child to finish is a configuration choice that you should verify in the Flowable CMMN documentation for your version.
- What it fits: (illustrative) a claims case that starts a separate investigation case when a fraud indicator appears.
- What the parent waits for: confirm the blocking behavior against the case task settings in your release.
- What returns: child case variables mapped back to the parent, and the child's final state.
- Reuse: one child definition can serve several parents, which limits duplicated modeling.
- Check: how terminating the parent affects a running child case.
Keep the child's inputs and outputs narrow so that parent and child stay easy to test.
A decision task evaluates a DMN decision table or decision from within a case. It suits rules that change often and need a business-readable table, such as eligibility or routing rules, where the case needs only the answer. The case evaluates the decision and continues, rather than running a long-lived unit of work. The output is the decision result, which the case uses in sentry conditions or later plan items. Confirm the exact input and output mapping and the decision versioning behavior in the Flowable DMN documentation.
- What it fits: (illustrative) a case that selects a review path from a risk tier table.
- What the case waits for: the evaluation completes in the same step, so no separate job is awaited.
- What returns: the decision output, which you map into a case variable.
- Change control: rule changes go through deployment of a new decision version.
- Check: how the decision result is typed and how missing inputs are handled.
Test each decision table against the inputs your case actually passes.
The three calls differ mainly in what they own and how long the parent depends on them. A process task owns a fixed sequence, a case task owns an open-ended body of work with its own lifecycle, and a decision task owns a rule that returns an answer. Picking the wrong one usually shows up later as awkward variable mapping or a parent that waits on work it should not. Ask who will change each piece and how often, since that drives whether the logic belongs in a process, a child case or a decision table.
- Fixed sequence: prefer a process task when steps always run in the same order.
- Reusable open-ended work: prefer a case task when the sub-work has its own stages and sentries.
- Changing business rules: prefer a decision task when the logic is a table that business owners maintain.
- Mixed needs: one case can use all three, each for the part it fits.
- Check: write down, per call, what the parent waits for and what it receives before building.
Review this comparison with the team that will maintain the models, not only the architects.
Each call type creates a dependency that needs its own test. A process task needs tests for the process outcome and its mapped variables. A case task needs tests for the child's final state and for what happens when the parent is terminated early. A decision task needs tests against sample inputs, including edge values. Plan these tests with the model, since a wrong mapping often passes a happy-path run and fails only when a variable is empty.
- Process tests: cover success, failure and the variables copied back.
- Child case tests: cover completion, termination and reuse by a second parent.
- Decision tests: cover each table row and missing input handling.
- History: confirm the history records show which call produced each outcome.
- Check: the Flowable CMMN and DMN docs for your release for the exact runtime rules, then test against your own version.
Blocking and non-blocking options and when each fits
This table compares the configuration choices that change how a case call behaves at runtime: how the parent waits, how data moves, how long the child lives, and how its completion affects the parent. Read each row as a decision: the right setting depends on whether the case needs the child's result before it can continue. Confirm exact attribute names and defaults in the Flowable CMMN documentation for your engine version before you model anything.
| Choice | Option and behavior | When it fits and trade-off |
|---|---|---|
| Wait behavior | Blocking: the plan item stays active until the called process or case completes | Fits when the next case step depends on the child's outcome. Trade-off: the parent's open plan item holds state and may wait a long time if the child stalls. |
| Wait behavior | Non-blocking: the call starts the child and the parent continues without waiting | Fits fire-and-forget work such as notifications or background fulfillment. Trade-off: the parent needs another mechanism, such as an event listener or milestone, to learn the result. |
| Variables in | Explicit mapping of case variables into the child's start variables | Fits calls where the child needs a bounded input set. Trade-off: every mapped name is a contract to maintain when either model changes. |
| Variables out | Explicit mapping of child outputs back into case variables when the child completes | Fits results the next sentry or task must read. Trade-off: outputs written after a non-blocking call may arrive after the parent has already moved on. |
| Child lifecycle | Child tied to the case: terminating or exiting the parent plan item also ends the child | Fits sub-work that has no meaning once the case moves on. Trade-off: a parent exit can cut off work that the business expected to finish. |
| Child lifecycle | Child independent: the process or case continues after the parent plan item ends | Fits long-running processes that outlive the case step. Trade-off: you must track and govern orphaned instances separately. |
| Completion effect | Parent plan item completes when the child completes, through the blocking wait | Fits strict sequencing where the case stage is done only after the child is done. Trade-off: failed or stuck children block stage completion. |
| Completion effect | Parent continues on its own rules, with completion driven by other plan items or listeners | Fits cases where the child is one of several inputs to a stage. Trade-off: completion rules become harder to reason about and test. |
How variables pass between a case, a process and a child case
The most important decision in this section is what each side of a call sees. A case, the process it starts through a process task, and any child case started through a case task each keep their own variables, and data only moves across the boundary through the input and output mappings you define on the task. Treat those mappings as the contract between the two models. Confirm the exact mapping syntax, including how input and output mappings are declared on process tasks and case tasks and whether the engine copies a variable into the child by default, in the Flowable CMMN and BPMN documentation before you rely on any shorthand. Also confirm how the engine handles a variable that exists on both sides with the same name, because that is where collisions appear.
Name collisions are the most common defect in these designs. A process variable called status and a case variable called status can look like a shared value when they are not, and an output mapping that writes back a value under a name the case already uses can overwrite state the case still needs for its sentries. Use explicit, prefixed names for values that cross a boundary, avoid relying on implicit scope, and write a test that starts the call, changes the child, and checks the parent value. Implicit inheritance also makes it hard for an auditor to answer which model produced a given value, so explicit mappings are easier to defend in review.
Passing a full payload, such as a customer record or a document, copies that data into the variable store of each instance and into history, and the copy then persists according to your history retention settings. Passing an identifier, such as a case file ID or a customer key, keeps the record in the system of record and lets the process or child case fetch what it needs under its own authorization. The trade-off is that the identifier design requires a lookup, a stable key and a clear owner for the data. Decide this per variable, and check with your security and records teams how history retention and access logging apply to any data that does reach the engine.
Setting up a case that calls a process and a child case
This sequence takes a case model from design to verified runtime, so that process tasks, child case tasks and decision tasks each start the right definition, pass the right variables and return control as intended. The output is a deployed set of BPMN, CMMN and DMN definitions and a test suite that proves each call path works.
Map each call point in the case design
Before any model is drawn, list every place the case needs to hand work to something else: a BPMN process task for a fixed sequence, a case task for a child case with its own plan items, and a decision task for a DMN table. For each call point, record which definition it calls, the input variables it needs, the output variables it expects back, and whether the case should wait for the call to finish. The architect and the process owner sign off this map. You know this step is done when every call point has a named target, an input list and an output list, and no call point depends on a variable nobody has assigned an owner.
Model the process and child case definitions
Build the target BPMN process and the child CMMN case as standalone definitions with their own keys, so each can be deployed and tested without the parent. In the parent CMMN model, add the process task, case task and decision task at the planned points, and set the reference keys to match the target definitions exactly. Confirm the referenced keys and the tenant or version behavior against the Flowable CMMN documentation for your engine version. You know this step is done when every call point in the case model resolves to a definition key that exists in the model set.
Deploy the BPMN, CMMN and DMN definitions
Deploy the child definitions before the parent case so that the reference checks pass at deployment time, then deploy the parent case and the decision tables. Use the same deployment pipeline your team uses for other definitions, and record the deployment identifiers and definition versions in your release notes. Confirm with your platform team how deployments are promoted between environments, because a parent that references a child version missing in the target environment fails only when the call is reached. You know this step is done when the engine lists every expected definition as deployed, with the versions you intended, in the target environment.
Wire the engine into the application
Decide whether the case engine runs inside your Java or Spring application or is called over HTTP through the Flowable REST application, since this choice sets how variables cross the boundary. In an embedded setup, the application starts cases and reads results through the engine's Java services; in a REST setup, your services send and read variables through the CMMN REST API. Configure the database and the Spring Boot starters for the engines you use, and confirm the supported database types and the starter versions for your release. You know this step is done when a test case starts from the application, reaches its first call point, and the engine reports the call as active.
Map variables across each call
Define the variable contract for every call: which parent case variables are copied into the child process or case, which outputs come back, and how names and types are kept consistent. Decide where mapping happens, in the task's input and output mappings in the model or in an application delegate, and keep the choice the same across the project. Watch for the case where a child writes a variable with the same name as a parent variable, because the scope rules decide which value the parent sees. You know this step is done when a written mapping table exists for every call and a test starts each call with a known input and reads back the expected output.
Test each blocking and non-blocking path
Write tests for each call path separately: a blocking process task where the case waits for completion, a non-blocking call where the case continues, a child case that must complete before its parent stage can complete, and a decision task that returns a value the case uses in a sentry. Include failure paths, such as a child that throws an error or a decision that returns no match, and check how the parent reacts. Keep the tests in your normal unit and integration test suite so that changes to a definition trigger them. You know this step is done when each path has a passing test and each failure path has a test that asserts the parent's visible state.
Verify the call history after each run
After the tests pass, check the history tables or history API for each test run to confirm the parent and child records are linked, the call order matches the model, and the variables recorded at each step match the mapping table. Keep these history checks as a repeatable script, since they are the evidence you will show operations staff and, where relevant, auditors. Confirm with your team what history level and retention settings apply to these case records, because they affect what the checks can see. You know this step is done when a reviewer can trace one case run from start to finish through the history and match every call to its target definition and its variable values.
Where blocking calls and variable mapping go wrong
Blocking process and case tasks fail in predictable ways: children that never finish, unbounded instance creation, oversized variables, mismatched versions, failed jobs and unclear ownership of completion. Each card below names one risk, the check that exposes it and the mitigation to build in before production.
Waiting on a child that never completes
A blocking process task or case task keeps its parent plan item open until the child finishes. If the child waits on a user task, a timer or a message that never arrives, the parent stalls with no visible error. Add a timer boundary or a timeout-driven exit path on the parent side, and review in-flight children with the monitoring tools your team already uses. Confirm which exit behavior your modeled tasks support in the Flowable version you run.
Unbounded child instance creation
A repetition rule on a process task or case task can start more children than the business intended, especially when it repeats over a collection variable that grows. Each child consumes database rows, history and async jobs. Cap repetition with a maximum instance count, size the collection before the case starts, and check the number of active children in test data sets that reflect production volume.
Large or sensitive variables copied into child scope
Mapping an entire case variable set into a child instance copies personal or regulated data into a scope that may have different access rules and a longer history retention. Map only the variables the child needs, use explicit input and output mappings, and keep identifiers rather than full records where the child can look up what it needs. Review the variables in history tables as part of data protection checks.
Version mismatch between calling and called definitions
A process task or case task can reference a definition by key, which may resolve to a newer version than the one your team tested. A change to the called process's variables or outputs can break the parent silently. Pin the version where your deployment process allows it, deploy called and calling definitions together, and run both in an integration test before promoting either.
Failed jobs in asynchronous continuations
When a task is configured as asynchronous, the continuation runs as a job picked up by the async executor. A failing job is retried, and the lock owner and lock expiration stored in the database let another node recover an expired lock and pick the job up. A job that fails repeatedly remains in the failed job list and blocks the parent until someone acts. Monitor failed jobs, set retry limits deliberately, and assign an owner for the failed job queue.
Unclear ownership of completion
When a child finishes, the parent may still wait on a sentry, an exit criterion or a required rule that depends on the child's outcome. If no one has written down which side decides completion, cases can stay open or close early. Document the completion contract for each child: the output variables, the terminal event and the parent plan item it satisfies. Test the case with the child completing, failing and being terminated.
Questions teams ask before building case-to-process calls
Can our team build process tasks and case tasks in Flowable without a partner?
Yes, a team with Java and BPMN experience can build these calls in-house, since Flowable is open source under Apache 2.0 and the engines are embedded or exposed through REST. The harder part is not the syntax but agreeing the variable contract between the case and each called process, writing tests for blocking and non-blocking paths, and deciding which failures the case must handle. Teams new to CMMN usually benefit from a short design review before building. Check your staff's experience with the engine's job executor and transaction behavior, since those decide whether a call behaves as the model shows. Ask any partner for a written scope that names the models, delegates and test cases included.
What drives the effort and cost of building these calls?
Effort scales with four things: the complexity of the case model, the number and shape of variable contracts between parent and child, the count of integrations the called processes touch, and the depth of testing you require. A case that calls one process with three input variables is a small job. A case that starts several child cases, waits on a decision table and passes large nested objects needs far more design and test time. Costs are mostly one-time for design and build, with recurring cost for maintenance when models change. When you request a quote, ask for the list of called processes and decisions, the variable mapping sheet, the integration endpoints, and the test matrix with blocking and failure paths.
How long does a case-to-process integration take to build?
Duration depends on scope, so no general figure applies. The main inputs are how many process tasks, case tasks and decision tasks the case uses, whether the called processes already exist or must be designed, and how many external systems they call. Teams often lose time in variable naming disputes and in waiting for test data, not in modeling. Ask a vendor for a schedule tied to named deliverables, such as an approved variable contract, a tested parent-child flow and a verified failure path, rather than a single calendar figure. Request the assumptions behind the schedule in writing so you can see which ones change it.
What do we need to provide for this work?
Plan for three inputs. First, domain experts who can confirm what each case stage must achieve, which outcomes count as complete, and what a decision means for the case. Second, access to a non-production environment with the same database type, identity setup and network paths as production, so job execution and integrations can be tested realistically. Third, your identity source, because tasks assigned to users or groups depend on how identities are resolved. Flowable's identity management can be replaced through its identity service interface, so confirm early which directory you will connect. Also confirm who approves changes to the variable contract after go-live.
Should we combine BPMN and CMMN in one application?
Combine them when part of the work is a predictable sequence and part is knowledge work that depends on what happens. A case can use a process task for the fixed steps, such as a verification flow, while the case itself handles the adaptive parts with sentries and milestones. Keep the boundary simple: one clear input contract per call, and avoid having a child process drive the parent case's state in hidden ways. If the whole flow is a fixed sequence, a single BPMN process is usually easier to test and operate. Review this choice with your engineers before the first model is drawn, because changing it later means reworking variables and tests.
What goes wrong when a parent case waits on a child process?
The most common problems are blocking calls that hold the case longer than planned, variables that change type between versions, and child processes that fail without the case noticing. A blocking task waits until the called process completes, so a slow external call can stall the parent. A non-blocking call lets the case continue, but then the case must handle the child's result through a later event or variable. Test both paths, including retries and a child that fails midway. Monitor failed jobs in production, since an unseen failure can leave a case apparently active while no work is progressing.
Do we need a formal quote before work starts?
Yes, a written quote is the right way to start. Most Flowable engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins. Ask for the quote to name the models in scope, the called processes and decisions, the variable contracts, the integrations, the test cases and the handover material. Ask also which items are one-time and which would recur, such as retainer support or changes after go-live. DeployOpen does not publish a price list, so a quote follows from that written scope.
How DeployOpen scopes and delivers Flowable case-to-process designs
DeployOpen approaches calling BPMN processes and child cases from Flowable CMMN as a written, fixed-scope engagement. We agree which case tasks, process tasks and decision tasks are in scope, then build, test and document them inside your own infrastructure.
How we scope
- Map each case stage and plan item to the process, child case or DMN decision it calls, and record the blocking or non-blocking choice for each.
- Agree in writing which variables pass between the case and each called element, including their names, types and direction.
- Confirm the Flowable version, database, Java and Spring baseline, and where the engines run before any build work starts.
How we build
- Model the process tasks, case tasks and decision tasks in your Flowable CMMN and BPMN definitions, with variable mappings kept explicit.
- Write unit tests for each case-to-process handoff, including the paths where a called process fails or a decision returns no match.
- Check async executor behavior for any non-blocking call so jobs are not lost or duplicated across nodes in your cluster.
How we hand over
- Deliver the case and process models, decision tables, variable contract and test suite as versioned artifacts in your repository.
- Document each call path, its blocking mode, its expected history entries and the operator steps for a stuck or failed child element.
- Walk your engineers through the design so they can extend the model after the engagement ends.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainer scope covers Flowable version upgrades, regression tests for case-to-process calls and review of changes to shared variables.
- Ask for the support boundaries, response expectations and upgrade approach in the written quote before work starts.
