When a DMN decision task in a CMMN case earns its place
A case earns a decision task when its routing depends on rules that change more often than the case model does. A decision task lets the case call a DMN decision and use the result to route work, activate stages or set case variables, so the case model keeps its shape while the business rules sit in a decision table that can be revised separately. If your case has sentries that embed eligibility thresholds, risk bands or priority matrices, and business owners ask for changes every few weeks, a decision task is the point where that logic moves out of the case diagram.
Flowable open source provides the CMMN and DMN engines as compact Java engines, with Java and REST APIs, under the Apache 2.0 license, as described on the Flowable open source page. Because the CMMN and DMN engines are separate components, a case can call a decision that is deployed independently of the case definition. Hard-coded sentries remain the better choice when the condition is a simple fact about the case itself, such as a document being attached or a stage being completed, and when the rule will not change without a change to the case model. Adding a decision table adds a second artifact to version, test and review, so the trade-off should be made deliberately.
Before you commit, confirm with your Flowable version and integration team how the decision task is configured in the release you plan to run, and how the engine resolves which decision version a running case uses. Ask who will own each table, how many decisions a single case will depend on, and whether the rules need an audit trail that the case itself cannot provide. Those answers decide whether the case stays readable as the number of decisions grows, and they belong in the design review before any case stage is wired to a rule.
Where decisions appear in a case: routing, stage activation and variables
A decision task can sit in several places in a Flowable CMMN case, and each placement gives the case a different kind of control. The cards below cover the common patterns, what each one gains, and what the rule owner must keep current as the case evolves.
Routing work to a human task
A decision task can choose which human task or stage receives a case item, so an intake rule decides whether a claim goes to a standard review or a specialist queue. The case gains one place where routing criteria are visible, instead of conditions scattered across task forms. The rule owner must keep the decision's output values aligned with the names of the task or stage the case expects. Confirm with your engine version how the decision result is mapped to a case item before relying on it.
Activating or skipping a stage
A decision result can determine whether an optional stage becomes active, so a credit case may skip enhanced due diligence for low-risk applications. The case gains a documented threshold for when extra work is required, which reviewers can trace. The rule owner must watch for stages that depend on outputs no longer produced after a rule change. Check how your CMMN model connects the decision output to stage activation, since the exact mapping depends on the engine version.
Setting case variables for sentries
A decision can write its outputs into case variables that sentries and plan item rules read later, such as a risk tier that gates a milestone. The case gains a single calculated value that many conditions can share, rather than repeating the logic in each sentry. The rule owner must keep variable names and types stable, because a renamed output can silently stop a sentry from ever firing. Verify variable mapping and sentry expressions against your Flowable version during design review.
Feeding one decision into another
An output from one decision can become an input to a later decision, so a classification decision feeds a pricing or eligibility decision. The case gains smaller tables with clear responsibilities, which are easier to test than one large table. The rule owner must track dependencies between decisions, since changing an early output changes every decision downstream. Ask your team to document the chain of decision keys and their expected inputs before each release.
Keeping dependencies visible to owners
When decisions drive routing, stages and variables at once, a single rule change can affect several parts of one case. The case gains readability only when owners can see which decisions touch which stages. The rule owner must maintain a mapping of decision keys to case elements and update it with every model change. Confirm with your team whether the Flowable tooling you use provides this view or whether it must be kept in your own documentation.
Choosing between a decision task, a sentry and a process call
When a single yes or no answer decides whether one plan item can start or complete, a sentry is usually the right place for the check. The sentry reads case data directly, so the condition stays next to the transition it controls. A decision task only earns its place when the gate depends on several inputs that business owners maintain in a table.
- Change frequency: Gate conditions usually change with the case design, so they ship in the same case definition release.
- Testability: Sentry expressions are exercised through case instances, which means your tests must set up the case state that reaches the gate.
- Audit trail: The case history records that a criterion was satisfied. Confirm in the Flowable CMMN documentation for your version what is recorded for each sentry evaluation.
- Input count: One or two variables are easy to read in an expression. Once the condition grows into a matrix of rules, move it into a decision table.
- Ownership: If a compliance or pricing team must review each change, a decision table gives them a document to sign off rather than an expression to parse.
Before adding a decision task to a gate, list the inputs the condition reads and who will change them, then confirm the choice with the owners of those inputs.
When one rule set decides which of several stages should activate, a decision task is the usual choice. It writes its result to a case variable, and sentries on each stage read that variable. The routing rules then live in one decision table that the business can review, while the case keeps only the structure of the stages.
- Change frequency: Routing outcomes often change with policy, so the mapping belongs in the decision table rather than in several sentries that each repeat it.
- Testability: The decision can be tested on its own with deployed DMN files, before any case runs against it.
- Audit trail: The decision execution history and the case variable both record the outcome. Confirm how your Flowable version stores decision history before you rely on it as evidence.
- Hit policy: If the table can return several matches, the case must handle a list of results. Choose the hit policy deliberately so that stage activation does not depend on rule order by accident.
- Variable naming: Many stages reading one unclear variable makes the case hard to follow. Name the output variable after the decision it represents.
Review the hit policy and the output variable name with the case designer and the business owner before the stages are wired to them.
When the logic is a sequence of steps with calls to systems, waits, retries and branches, it fits better in a BPMN process that the case calls. The case then manages the lifecycle of the work, and the process carries out the procedure. Decisions can still be called from inside that process where a rule is needed, so each kind of logic stays in its own model.
- Change frequency: Procedures change on their own schedule. Version the process separately and confirm which version running instances pick up after a deployment.
- Testability: Process behavior is tested through the engine with stubbed delegates or services, and the decisions inside it are tested separately.
- Audit trail: The process history holds step-level evidence, while the case history shows the stage and milestone transitions that matter to the case reviewer.
- Readability: A case with a long chain of sentries that each read intermediate variables to replay a sequence is a signal that the sequence belongs in a process.
- Failure handling: Retries and error paths are easier to reason about in a process, where job failures are visible to operations teams.
For each sequence you plan to move, confirm which team owns the steps, how the process version will be released, and where the reviewer will look to see what happened.
Configuration options and when each fits
This table compares the main choices for a decision task in a Flowable CMMN case: which decision it calls, how case variables feed its inputs, where its output goes, and which version it uses. Read each row against the Flowable CMMN documentation for the version you deploy, because attribute names and behavior should be confirmed there before you commit to a design.
| Choice | What it controls | When it fits | What to confirm |
|---|---|---|---|
| Decision key | The DMN decision the task evaluates, referenced by its key | One decision per task suits a single routing question; a shared decision suits rules reused across several cases | Exact attribute used to reference the decision key in your Flowable version |
| Input mapping from case variables | Which case variables feed the decision inputs and under which names | Explicit mapping fits cases with many variables, because the rule input contract stays visible in the case model | Whether unmapped variables are passed by default and how missing values are handled |
| Output to a case variable | Writes the decision result into a case variable that later sentries or tasks read | Fits routing data that several plan items need, such as a risk tier or a priority | How result types are converted and which hit policy shapes the output (single or list) |
| Output to stage activation or sentry input | Uses the result to satisfy or trigger a sentry that activates a stage | Fits cases where a rule decides whether an optional stage starts, keeping routing logic near the stage it controls | How sentry conditions reference decision output and what happens when the decision returns no match |
| Pinned version | The case calls one specific decision version fixed at design or deployment | Fits regulated work where every case must show which rule version applied and changes need a deliberate case update | How the version reference is written and whether pinned references survive redeployment |
| Latest deployed version | The case calls whichever version is currently deployed under the decision key | Fits rule sets that change often and must apply to open cases without a model change | Which version running cases pick up after redeployment and how to test that behavior |
| Decision per tenant or per variant | Separate decision keys or tenant-scoped deployments for different business units | Fits organizations with different rules for each unit, keeping case models identical | Tenant handling in the decision task and how deployments are scoped in your engine version |
How to set up a decision task in a CMMN case
This sequence takes a business rule from agreed inputs and outputs to a deployed Flowable DMN table that a CMMN case calls at the right moment, with sentries or plan item rules acting on its result. Each step ends with a check so the routing can be confirmed before the case goes live.
Agree decision inputs and outputs
Work with the business owner to list every input the rule needs, such as case file fields, customer attributes or earlier decision results, and every output the case will act on, such as a route name, a stage to activate or a value to store in a case variable. Record the data type, the allowed values and what happens when an input is empty. This is done when the owner signs off a short input and output table that names each column the decision table will read and write, so developers and reviewers work from the same definition.
Model and deploy the DMN table
Build the decision table in your modeling tool with inputs, outputs and rules that match the agreed table, choosing a hit policy that fits how many outputs each case can produce. Deploy the file to the Flowable DMN engine in the environment where cases will run, using the same deployment pipeline you use for other definitions. Confirm that the deployed decision key and version match what the case will reference. Check the deployment result through the engine's query API or the REST deployment endpoints before going further.
Add the decision task to the case
In the CMMN model, add a decision task to the stage or plan model where the routing is needed, and point it at the deployed decision key. Map case variables to decision inputs and map decision outputs back to case variables, so that the result is stored under a name the rest of the case can read. Confirm the mapping for a sample case instance by inspecting its variables after the task runs. If your project uses Spring Boot starters to wire the DMN engine, verify that configuration as described in the Flowable Spring Boot documentation before testing.
Connect the output to sentries and rules
Use the decision output in sentries or plan item rules so that the case activates a stage, enables a task or moves to a milestone only when the expected value appears. Keep the condition in the sentry readable, referring to one named case variable per route instead of repeating rule logic inside the case model. Where many decisions feed one case, group them by stage so that each sentry shows which decision it depends on. The step is complete when every route in the table has exactly one sentry or rule that leads to it.
Test each routing path
Run a set of sample case instances, one for each output value and one for each boundary input that the table defines, including empty or unexpected values. Confirm that each sample reaches the expected stage or task and that no unintended stage activates. Repeat the test after any change to the table or the case model. This step produces a short test record listing input, expected route and observed route for each sample, which the business owner can review.
Confirm decision history rows
Query the decision history for the sample instances and confirm that one record exists for each decision execution, showing the decision key, version and the output that was returned. Check that the history matches the route each case took. Confirm with your team whether history persistence is enabled in the target environment and how long those records are retained, because this affects both audit evidence and storage volume. The step closes when history rows match the test record for every sample.
How to keep case logic readable when many decisions are involved
The most useful decision you can make in a CMMN case with several decision tasks is to keep the case model showing intent and let the decision tables hold the detail. A reviewer should be able to read the case plan and see the stages, milestones and sentries that define the business process, while the rule logic stays in DMN files that can be read and tested on their own. Give each decision task a key that names one concern, such as credit-tier-routing or document-completeness, rather than a generic key like decision1. One decision per concern makes it obvious which stage depends on which rule and lets a business owner find the table they need to review.
Set a naming convention for case variables before the first decision is wired in. Decision tasks write their results into case variables, so the variable names become part of the case contract. Agree on a prefix or pattern, for example one that marks variables written by decisions versus variables entered by people, and document which decision writes which variable. Confirm in the Flowable CMMN and DMN documentation for your version how decision task outputs are mapped to case variables, and check that a variable written by one decision is not silently overwritten by another. Keep the list of output variables short so sentries and plan item rules can refer to them without the reader tracing a long path.
Avoid chains where one decision feeds another, which feeds a third, all inside the same case. Each link adds an invisible dependency that is hard to debug when a sentry fails to fire. If a decision depends on the output of another, consider whether the two belong in one decision table, or whether the upstream result should be recorded as a case variable that the stage explicitly reads. Review the case for decisions that run in sequence only because of data flow, and check whether the case plan still makes sense to a non-engineer. Plan a review step with the rule owners to decide where the boundaries sit, because those boundaries determine who can change a rule without changing the case model. Versioning of decisions is covered in the deployment and versioning sibling page.
Security and operational risks to plan for
Decision tasks connect rules, case state and job execution, so a failure in any one of them can change how work is routed. The cards below cover the risks that most often surface after a case goes live, and the checks to agree before the first release.
Unauthorized decision table changes
A decision table decides which branch a case takes, so an edited rule can reroute work without any change to the case model. Restrict who can deploy DMN files to the environments that run cases, and require review of every hit policy and output change. Ask whether your pipeline records who deployed each decision version and keeps the previous version available for rollback.
Sensitive data in decision inputs
Case variables passed into a decision task become decision inputs, and depending on your history settings, they can also end up in stored execution records. Map only the fields a rule needs, rather than passing whole case payloads. Confirm with your security team which variables count as personal or regulated data and where history for those cases is retained.
Missing authorization on case actions
The engine does not decide who may start a case, create a case instance or advance a stage manually. Those checks belong to your application, so a user who can call the API directly may be able to trigger a decision path they should not reach. Document which roles can start, complete or reopen each case type and test those checks with negative cases.
Failed or stuck timer jobs
Cases that wait on timers depend on the async executor, which runs jobs on a thread pool and coordinates nodes through locks stored in the database. A failed job can leave a case waiting when no one has been alerted. Review how the async executor and lock behavior are configured for your cluster, and agree who responds when a job fails, with the lock expiry settings taken from the Flowable advanced docs.
Monitoring through the actuator endpoint
When the Spring Boot starters are used, the actuator endpoint at /actuator/flowable exposes information about running processes, which helps you see cases that stall. Decide which metrics you alert on, such as growing counts of waiting instances or failing jobs, and confirm that the endpoint is not exposed publicly. Check the exposure settings in your Spring Boot configuration before go-live.
Questions teams ask before building decision-driven cases
How much extra effort does a decision task add to a CMMN case build?
A decision task adds moderate effort on top of the case model itself, and most of it sits in the rule design and the wiring of inputs and outputs. The case work covers the decision task plan item, the sentries and stage activation that read its results, and the case variables it writes. The decision work covers the decision table, its inputs and outputs, and the test cases. Effort rises with the number of decisions, the number of inputs per table, how many business owners must agree on the rules, and how many rule overlaps the hit policy must handle. Ask any partner to split the quote into case modeling, decision design, integration and testing so you can see which line items grow with your rule count.
What skills does a team need to build decision tasks in Flowable cases?
The team needs three kinds of skill. CMMN modeling skills are needed to design stages, sentries, milestones and plan item rules that wait for decision results. DMN skills are needed to write decision tables with clear inputs, outputs and hit policies. Java and Spring knowledge is needed to deploy the engines, call them from application code, and run tests, because Flowable is embedded in Java applications and exposes Java and REST APIs. Business owners must also give steady time to confirm rule logic, since the tables are only as correct as the rules the business agrees to. Teams without one of these skills usually need a short ramp-up or outside help for that part.
Can our own team build decision-driven cases without a partner?
Yes, a capable Java team can build them alone, provided it has the skills listed above and time to test rule changes with the business. Flowable is open source under the Apache 2.0 license, and the engines can be embedded in Java SE, servlet, Spring or Java EE applications. The risks for an in-house build are usually not the engine itself but the gaps around it: unclear rule ownership, missing regression tests, and no plan for how decisions change after go-live. A partner is most useful when the team needs a fixed scope with a written plan, a second set of eyes on the case and decision design, or handover that the internal team can run.
How long does a first routed case take to deliver?
Duration depends on scope, and a credible figure can only come from a written plan. The main inputs are the number of cases and decisions, how many systems the case must call, how mature the business rules are, and how quickly business owners can review them. Ask for a fixed-scope plan that lists each case, each decision table, each integration, the test approach and the acceptance steps, with dates tied to those items. Be cautious of any timeline given before those inputs are known. A small first case with one decision and clear rules will move faster than a case that depends on unsettled policy.
Can decision rules change without redeploying the case?
Often yes, but this needs to be designed in from the start. In Flowable, decision tables are deployed as their own definitions, and a case that calls a decision by key can pick up a new decision version without the case model being redeployed. Whether a running case instance uses the new version depends on how the decision is referenced and when it is evaluated, so confirm that behavior in your version before you rely on it. Plan for decision keys and versions, one decision per file where practical, and tests that run each new version against the existing rule set before release.
What should a partner hand over at the end of the engagement?
A complete handover lets your team run the cases and decisions without the partner. Ask for the CMMN case models and DMN decision files in source control, the Java code and configuration that call the engines, the automated test suite with test cases per rule and hit policy, and a document that records which business owner approved each rule set. Also ask for a runbook covering deployment, decision versioning, the decision history settings you chose, and how to add or change a rule. Confirm that training sessions, knowledge transfer and any post-handover support are written into the scope, since they are priced separately from the build.
What does a quote for this work need to include?
A quote should list each deliverable and the work behind it, so you can compare it with an internal estimate. Ask for line items for case modeling, decision design per table, integration with the systems the case calls, test design and automation, deployment, business review sessions, handover and any support period. Each line should name what is one-time, such as the initial build, and what recurs, such as rule changes after go-live or a retainer for upgrades. Ask which assumptions the price depends on, such as the number of business owners available for review and the state of the source rules. DeployOpen does not publish a price list, so the quote follows from the written scope.
Limits to confirm in your Flowable version and environment
Decision tasks inside CMMN cases depend on the exact Flowable version, the Spring stack around it, the database you run and the volume your cases generate. The items below are the points to confirm with the Flowable docs or in a test environment before you commit to a design.
Decision task and variable mapping support
Confirm that your Flowable version supports the decision task configuration and the input and output variable mapping your case needs. Check how the case reads the decision result, how it handles a missing or empty result, and whether the mapping works the same way in your version as in the examples you plan to copy. Build one small case in a test environment that uses each mapping pattern before you design the full model.
Spring Boot baseline for your version
Flowable 8.0.0 was released on February 27, 2026, and it requires Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3. If your application runs Spring Boot 3, the choice is an upgrade of the whole stack or a move to an earlier Flowable line. Confirm the baseline against the release notes before you plan the case work.
JSON library behavior with Jackson 3
Flowable 8.0.0 uses Jackson 3 as its default JSON library and provides a Jackson 2 compatibility layer. Case variables that hold objects, and any custom code that serializes them, can behave differently under each library. Test how your decision inputs and outputs serialize, and decide whether to rely on the default or the compatibility layer before your custom delegates and REST clients depend on the output format.
Database support for your history volume
Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server. Cases that call decisions often generate large volumes of history, and the database you choose must hold that volume with the retention and backup targets your organization sets. For MySQL, confirm the server version, since versions below 5.6.4 lack millisecond precision, which matters when you order history events.
Async executor tuning for case volume
Timers and asynchronous jobs run on the async executor, which coordinates several nodes through lock owners and lock expiration times in the database. Cases with many timers, sentries or asynchronous decision calls may need thread pool and lock settings sized for your load. Measure job throughput in a load test with your real case mix, and confirm how expired locks are recovered when a node stops.
How DeployOpen scopes and delivers decision-driven Flowable cases
DeployOpen plans, implements, tests, documents and supports self-hosted open-source platforms inside your own infrastructure. For Flowable DMN decision tasks in CMMN cases, we start by agreeing in writing which cases, stages and decisions are in scope, then build and test the case model and decision tables together before handing them over with the documentation your team needs to run them.
How we scope
- Inventory the cases, stages and decision tasks that call DMN decisions, and name the owner of each decision table.
- Record which case variables feed each decision and which outputs drive sentries, plan item activation or routing.
- Agree in writing the deliverables, exclusions and timeline before work starts, since most engagements are fixed-scope.
How we build
- Model case plan items and decision tasks in CMMN so each rule call has a named input contract and documented result handling.
- Build decision tables with agreed hit policies, and keep case logic readable by grouping related decisions into stages.
- Test each case path and decision result against deployed DMN files, and review results with the business owners before release.
How we hand over
- Deliver the case and decision models, deployment steps, variable dictionary and test suites in your own repositories.
- Document how decision versions are released and which version running cases pick up, so operations staff can follow the process.
- Walk your engineers and business owners through the models, the runbook and the open items that remain after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
- Retainers can cover rule changes, regression runs after Flowable upgrades and reviews of new decisions added to existing cases.
- Confirm response expectations, environments covered and upgrade responsibilities in the written retainer scope before signing.
