Why Flowable CMMN manual activation and required rules decide when case work starts and ends
Manual activation and required rules decide when case work starts and when a case or stage can close. In a Flowable CMMN case, some tasks should wait until a person decides to start them, while others must finish before a stage can complete. Manual activation rules control the first part, and required rules, along with completion neutral and parent completion rules, control the second. Teams need to model these choices deliberately because a case that looks correct on a diagram can stall or close early at runtime if the activation and completion behavior does not match the business process.
Start by listing every plan item in the case and labeling it as one of three things: work that starts automatically when its entry criteria are met, work that a person must start manually, or work that must finish before its stage can complete. Then, for each group, check the Flowable CMMN documentation for the version you run to confirm the exact semantics of the manual activation, required and completion rule settings, including how they interact with sentries and with the parent stage. Do not assume that behavior carries over from BPMN gateways or from another CMMN engine. The behavior is defined by the engine version you deploy, so the check belongs in your design review, not after go-live.
The decisions that matter most are who may start an optional task, which work genuinely blocks completion of a stage, and what the case should do when a required item is never addressed. Each answer maps to a model setting, and each setting needs a test case that starts the case, leaves the optional work untouched, and tries to close the stage. Ask your implementation partner or internal team to show those tests in the written scope, and confirm which Flowable release line your platform will run, since the engine versions in use change over time and the documentation for each release is the authoritative reference.
Which rule fits each kind of Flowable case work
This table compares manual activation, required, completion neutral and parent completion rules by what each controls, the case work it suits and the questions to settle before choosing one. Read each row as a modeling decision for one piece of work, then check the questions against your process owners before you set the rule in the case model.
| Rule | What it controls | Case work it suits | Questions to answer first |
|---|---|---|---|
| Manual activation | Whether an optional plan item waits for a person or system to start it instead of starting as soon as its entry criteria are met | Optional follow-up tasks, such as a supplementary document request that a caseworker decides to raise | Who decides to start the work, what information they need to decide, and what happens if nobody starts it |
| Required | Whether the stage or case can complete while this plan item is still open | Mandatory checks that must finish before the stage can close, such as identity verification in an onboarding stage | What the business treats as a failed or skipped outcome, and whether a termination path must exist for the blocked item |
| Completion neutral | Whether the item's state is ignored when the enclosing stage or case decides it has completed | Informational tasks, notifications or optional reviews that should not hold up closure | Would closing the case without this item cause an audit or customer gap, and is its outcome still recorded if left open |
| Parent completion | Whether the completion of this item is taken into account when deciding completion of the parent stage or case | Work whose status should roll up to a stage summary or case status report, such as a sub-review feeding a credit decision stage | Which parent status reporting depends on this item, and how the parent should behave if the item is terminated or never reached |
| Combined rule set | How required, manual and completion settings interact on one plan item within a stage | Stages with a mix of mandatory and optional work where some items wait for people | Which items must close before closure, which can stay open, and whether a reviewer can see open optional items at closure |
| Test scenario coverage | Whether each rule outcome is exercised in tests before release | Any case model where completion depends on the rules above | Which paths (completed, terminated, never activated) the team will test, and who signs off the expected result |
How required rules and parent completion decide when a stage can complete
A stage or case completes when the CMMN engine finds that its children no longer need to run and that nothing blocking remains. The engine works through the child plan items of the stage: each one is either in a terminal state (completed, terminated, or disabled), or it is still active, enabled, available, or waiting for manual activation. A child marked as required blocks the parent from completing until it reaches a terminal state, while a child that is not required does not hold the parent open. Plan items with a completion neutral rule are treated as not blocking even when they never finish, which is how an optional task can stay open after the work it supported is done. Confirm the exact order in which your Flowable version evaluates required items, completion neutral items and the parent's own completion rule, since that order decides what a case reports at the moment it finishes.
Human work is where this evaluation most often surprises teams. A stage that contains a human task waits in the active state until a user completes or terminates that task, so a required human task can keep a whole case open for as long as someone does not act. Because a task that is still enabled is not yet a terminal state, a case with a required task that nobody claims will not complete, even if every other item is finished. Decide, before modeling, which human tasks truly gate the outcome and which are advisory, and make the advisory ones completion neutral or non-required. Then test a case with those tasks left unattended to see whether the case stays open as intended.
The parent's completion also depends on what its children are doing, not only on whether they exist. A stage's own completion rule can be combined with its children's states, so a stage can finish while optional children are still active, or it can wait when a single required child is stuck. Write a test for each path: all required children completed, one required child terminated, and a manually activated child left unactivated. Record the results against the Flowable version you run, and check the completion rule in your version's CMMN documentation before you rely on it for reporting or for triggering the next stage.
Setting up manual activation and completion rules in a Flowable case model
This sequence turns a list of case work items into a tested case model where optional work waits for a person to start it and the case completes only when the required work is finished.
Inventory the work items in the case
The case owner and a Flowable modeler list every task, stage and milestone the case may need, with a short business description for each. Include the people who perform the work and the evidence that shows it is finished. Review the list with the business owner so that each item matches a real activity. The step is done when the list is agreed and every item has a name the team can use in the model.
Classify each item as mandatory, optional or informational
For each work item, decide whether the case cannot complete without it (mandatory), whether a person may choose to start it (optional), or whether it only records information for reporting (informational). Record the reasoning next to each item, because auditors and reviewers will ask why an item is required. Confirm the classification with the business owner and the compliance lead where the case supports a regulated process. The step is done when every item has one classification and a short justification.
Assign activation and completion rules in the model
In the CMMN model, set the manual activation rule on each optional task so it waits for a user to start it instead of starting automatically. Mark mandatory plan items as required so they must reach a completed state before the stage or case can complete, and use completion neutral settings for informational items that should not block completion. Check the rule options against the Flowable CMMN documentation for your engine version, since the exact property names and defaults should be confirmed in your own setup. The step is done when the model validates and each plan item shows the rule you chose on paper.
Deploy the case definition to a non-production engine
The platform team deploys the updated case definition to a non-production Flowable engine using the pipeline your organization already runs for process and case definitions. The exact modeling tool, packaging and deployment path depend on how your team runs Flowable, so confirm them with your engineers before this step. Confirm that the deployment succeeds and that the new definition version is the one the engine reports as active. The step is done when the deployed version matches the version you reviewed.
Start test instances and check manual activation
A tester starts a case instance and inspects its state through the engine API or the administration tooling your team uses. Confirm that each optional plan item with a manual activation rule stays in an available state and does not start until a user acts on it. Then trigger that action and confirm the item moves to the expected next state. The step is done when every optional item behaves as the model specifies and the results are recorded against the test case.
Test completion attempts against required items
The tester attempts to complete the stage or case while mandatory items are still open, then again after each mandatory item is finished. Confirm that the stage or case does not complete while a required item is still open, and that informational items do not block completion. Include a test where an optional item is left unstarted to confirm it does not hold the case open. The step is done when each completion attempt produces the state you expected and the outcome is written down for each scenario.
Check plan item states after completion attempts
After each completion attempt, the tester reviews the state of every plan item and compares it with the classification from the inventory. Any item in an unexpected state is traced back to its rule before the model is changed. Repeat the check for terminated or cancelled paths if the case allows them. Ask your Flowable specialist to confirm how the engine reports these states in your version. The step is done when every plan item state matches the agreed design and the tests can be rerun by someone who did not write them.
Modeling mistakes that leave cases stuck or closing too early
Most stuck or prematurely closed Flowable cases trace back to a small set of modeling choices about which work is required, who owns each open item, and what a parent waits for. The cards below describe each mistake as an operator sees it and the check that catches it before go-live.
Required work that should be optional
Marking a task as required when the business only expects it sometimes is the most common cause of a case that cannot finish. The stage waits on a plan item that nobody is ever asked to start, so the case sits open with no visible blocker. Before go-live, walk every required plan item and ask whether a real business path exists where it never happens. If not, make it optional or move it behind a manual activation rule that a named role controls.
Child items with no owner
A child plan item that is enabled but has no assignee, candidate group or automatic trigger can hold its stage open indefinitely. Operators see a stage that never closes and no human task waiting in their queue, which makes the problem hard to trace. Check each enabled item in the case model for an owner or an automatic path to completion, and confirm that the group named in the model exists in your identity source.
Informational tasks treated as blocking
A task meant only to inform or record a notice can be modeled as required, which turns a status update into a gate. Users then see the case refuse to close until someone clicks through a task that carries no decision. Review each required task and ask what the business would lose if it were skipped. Tasks that only inform should be optional or marked as non-blocking in the model, with their purpose written in the task name or documentation.
Parents assumed complete when children only started
Teams often expect a stage or case to complete once its children have been started. In Flowable, completion depends on the completion rule and on the state of each child, so a parent can stay open while children are active, or close while a started child is still running if the rule allows it. Test the completion neutral and parent completion rules with children in each state, starting, active and completed, and confirm the outcome before release.
How to test completion behavior before a case goes live
Unit-style checks run one case definition against the CMMN engine in a test harness, with no front end and no external systems. The goal is to confirm that each stage and task reaches the state its rules imply under controlled inputs. Start with the smallest case that exercises one rule, then add the surrounding plan items until the full definition is covered. Keep the test data small and explicit so a failing assertion points to one rule.
- Required items: Start the case, complete every required task in one run, and assert that the stage or case completes. Then repeat with one required task left open and assert that it does not complete.
- Manual activation: Assert that an optional task with a manual activation rule stays in its available state until a user or API call enables it, and that it does not start on its own.
- Completion neutral items: Terminate or leave open an item marked completion neutral and confirm that the parent still completes when its required items are done.
- Parent completion rules: Check that a stage or case with a parent completion rule waits for the children it names, and not for siblings outside that set.
Confirm which test utilities the chosen Flowable version provides and whether they cover case state assertions before writing custom helpers. Check the state after every rule, not only the final state.
End-to-end runs deploy the case definition to a running engine and drive it through the Flowable CMMN REST API or the Java API, as a front end or integrating service would. This tab finds problems that unit checks miss, such as variables that are set too late, plan items that are not enabled in the order the application expects, or a manual activation that the application never triggers. Use a database that matches production so timing and transaction behavior are realistic.
- Case state after completion: After completing the required plan items through the API, assert the case instance state and the stage states, not just the response code of each call.
- Open items at completion: Leave optional items open and assert whether the case completes or stays active, and that the open items are reported as expected.
- Manual activation calls: Enable a manually activated item through the API and assert that it moves to the active state and that completing it allows the parent to finish.
- Negative paths: Try to complete an item that is not yet enabled and assert the engine rejects it with a clear error.
- Test data: Prepare case variables for each branch, including missing or null values, and seed users or groups if human tasks are involved.
Confirm the exact REST resources and endpoint behavior for your Flowable version in its REST documentation before scripting the calls.
Business owner review checks whether the rules match the work the organization actually requires. Engineers can verify that the engine behaves as modeled, but only the people who own the process can confirm that the model's required items are the ones that must finish before a case is closed. Run this review with a set of written scenarios rather than a walkthrough of the diagram, so owners judge concrete outcomes.
- Scenario list: Prepare a short list of realistic cases from the business, each with the outcome the owner expects, such as which items may remain open at closure.
- Required versus optional decisions: Ask the owner to mark every item as required, optional or completion neutral, and compare that list with the model.
- Exception handling: Walk through what happens when work is abandoned or superseded, and confirm whether the case should complete, terminate or wait.
- Sign-off record: Record the agreed scenarios and the owner's approval so the decision can be traced later.
- Test data from production: Where policy allows, use anonymized historical examples that show the real mix of optional and required work.
Confirm that the scenarios and sign-off are stored with the case definition version they approve, so a later change to the rules triggers a new review.
What to confirm for your Flowable version before relying on these rules
CMMN completion and activation behavior is defined by the engine version you run, the model you deploy and the code around it. Each card below names one thing to verify in your own environment before a case is allowed to start or finish on these rules.
Flowable version and release notes
Record the exact engine version in your build file and read its release notes before relying on any rule. Major releases in this line have changed the Java, Spring and Jakarta baseline and removed components, so a version that works in a test case may not match production. Ask whether the release notes for your version mention any change to plan item or sentry behavior, and rerun your case tests after every upgrade.
CMMN rule semantics for your version
Confirm in the Flowable CMMN documentation for your exact version how manual activation, required, completion neutral and parent completion rules evaluate. Check which plan item states count toward a stage or case completing, and whether an optional task still blocks completion when it has not started. Write down the answers as expected behavior before modeling starts.
How the case model is authored and deployed
Confirm which modeling tool your team uses and whether the rule attributes in the saved CMMN XML match what the engine reads after deployment. Check that the deployed definition is the one running in each environment, since a stale deployment can keep an old completion rule active. Ask who owns model review and whether a rule change needs a new definition version.
Case state in history
Test whether history records each plan item transition, including manual activation, completion neutral outcomes and the moment a stage completes. Your compliance and support teams will need these records to explain why a case closed. Confirm the history level your deployment uses, and check that the records you need are kept long enough for your audit window.
Custom code that changes completion
Review every listener, expression and Java delegate that sets variables or calls the engine on a case. A script that changes a variable read by a sentry or a rule can alter when a stage completes without any change to the model. List these hooks, assign an owner to each, and include them in your regression tests so that a code change is caught before it reaches production.
Who can activate work and how completion rules are protected in operation
Manual activation is a human decision, so the first operational question is who may start a manually activated task and who may complete a human task. Flowable executes the plan item lifecycle, but the engine does not decide which person is allowed to trigger a transition. Authorization checks for case and task actions are left to your application, which means the access rules must be designed in your front end and service layer and then tested against the exact API calls your version exposes. Confirm the authorization hooks for your Flowable version with the CMMN documentation and your own code before you assume any action is blocked by default. Record the role model for each human task in the case model documentation so reviewers can see it next to the completion rules.
Operations teams need visibility into cases that wait on manual activation. A case that has reached a stage with an optional task awaiting a person can look healthy while nothing is happening, so build a query for active plan items in the enabled state that have not moved for longer than your agreed service window. Watch for stuck cases after a model change: when you deploy a new case definition, confirm how existing instances will behave and plan any migration of running instances before release, because a required rule that no longer matches the model can leave a case unable to complete. Test completion on representative instances in a non-production environment first.
Audit records must show who activated or completed each piece of work. Store the user identifier that the application passes with each transition, and keep it alongside the case instance and plan item history that Flowable retains. Confirm with your version's documentation which history levels and tables capture plan item transitions and completion events, and how long they are kept. Auditors will ask whether the recorded actor matches an authorized role at the time of the action, so the application log and the engine history should be reconciled during testing. Agree on this design with your compliance and security owners before the case goes live.
Questions teams ask before modeling Flowable CMMN completion rules
How much effort does it take to model manual activation and completion rules?
The effort depends mostly on the number of plan items and how many of them carry manual activation, required or completion neutral rules. A case with a handful of optional tasks and one stage usually needs a short modeling pass, while a case with many nested stages, parent completion dependencies and exceptions needs a longer design phase before any XML is written. Effort also rises when the rules encode policy that nobody has written down yet. Ask any partner to break the estimate into modeling, review, test cases and documentation, and to state which of these are one-time and which recur when the case changes.
Can an internal team model these rules without outside help?
Yes, an internal team with CMMN experience can model these rules, and many do. The skills that are hardest to build internally are usually not the XML itself but the habit of writing down completion criteria, testing every combination of optional and required work, and checking how a stage behaves when a human task is never completed. Teams new to Flowable should plan for a learning curve on the CMMN specification and on how the engine evaluates plan items. A partner can supply a review, a test approach and a worked pattern, while your team keeps ownership of the model.
What do business owners need to provide for completion rules?
Business owners must define, in plain terms, what finished means for each stage and for the case as a whole. That includes which tasks are mandatory, which can be skipped with a documented reason, and whether a stage can close while a child task is still open. Each rule should trace to a policy, a service level or a regulatory step that the owner can point to. When owners disagree, the model will reflect whichever answer was chosen last, so agreement should be recorded before modeling starts. Expect several review rounds with the same people.
How long do review and testing usually take for a case of a given size?
Review and testing scale with the number of plan items, the number of distinct completion paths and the number of stakeholders who must sign off. A small case with one path can be reviewed in a single session, while a large case with several stages and parent dependencies needs a test matrix that covers each combination of optional and required work. No general duration is supplied for this work, so ask any partner to show the test matrix and the review plan they would use for your case, and to state what each review round depends on.
What changes after a completion rule is updated in the model?
A rule change affects new case instances from the point the new definition is deployed, but running instances stay on the version they started with unless you migrate them. Changing a required rule to a non-required one may let a stage complete earlier than before, and changing a parent completion rule can leave child work open in ways the old model never allowed. Each change should be tested against both new and running instances, and the test should confirm that existing cases still reach a valid end state. Flowable provides case instance migration, which should be validated first in a non-production environment.
Which factors drive the cost of completion rule work up or down?
Four factors shape most of the cost: the number of plan items, the number of stakeholders who must agree on completion, the number of exception paths, and the depth of test coverage. Cost rises when completion depends on several teams, when rules change often, or when the case must be audited against written criteria. It falls when the process owner has clear, written rules and when the case is kept small enough to test completely. Ask for a quote that separates modeling, stakeholder workshops, test design, test execution and handover, so you can see where each cost sits and which parts you can absorb internally.
What does a partner need from our side to start this work?
A partner needs the current case description, any existing BPMN or CMMN models, the list of plan items with their intended behavior, and named owners who can answer questions about completion. Access to a non-production Flowable environment and a sample of realistic case data also speeds up testing. Your team should also confirm which Flowable version you run, because the engine version determines which features are available. Scope is agreed in writing before work starts, so list every stage and rule that is in and out of the engagement.
How DeployOpen scopes, builds and verifies Flowable case models
DeployOpen plans, implements, tests, documents and supports self-hosted open-source platforms inside your own infrastructure, including Flowable CMMN case models. For manual activation, required and completion rules, we start from the written business rules for each stage and task, then build and verify the case behavior against them before handover.
How we scope
- Engagements are fixed-scope, with the case definitions, rule inventory and deliverables agreed in writing before work starts.
- We list every plan item that is manual, required, or completion neutral, with the business owner who decides when it can start or finish.
- The scope names the parent stage and case completion conditions that each rule feeds, so the boundary of the work is explicit.
- We confirm which Flowable engine version and deployment model the case models will run on before modeling begins.
How we build
- We model manual activation and required rules in CMMN case definitions and check them against the agreed rule inventory.
- Completion neutral and parent completion settings are configured and reviewed for each stage that gates case completion.
- Automated tests cover paths where required tasks are left open, completed out of order, or blocked by a child case.
- Case variables and event listeners that trigger manual activation are documented alongside the model they affect.
How we hand over
- Handover includes the case models, a rule reference describing each activation and completion condition, and the test suite.
- Runbooks explain how operators see which required items are still open and how to resolve a stuck case safely.
- We document which settings were changed from defaults so your team can review and maintain them after handover.
- Knowledge transfer sessions walk your engineers through the models, tests and change process for future rule updates.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, covering case model changes after go-live.
- Regression tests for activation and completion rules can be re-run when Flowable versions or case definitions change.
- Change requests to rules follow the same written scope process, so each change has a defined deliverable and test coverage.
- Ask any provider to confirm how they test rule changes against running case instances before a production release.
