Why teams move Flowable DMN decision tables out of code
Many Flowable process applications start with business rules written directly into service task delegates or expressions. Eligibility limits, routing thresholds and pricing bands then sit inside Java code, so every change to a rule waits for a developer, a code review and a release. When those rules change more often than the application does, a Flowable DMN decision table is the usual way to move them out of code. A decision table is a set of input columns, output columns and rule rows that a process or case evaluates at runtime, and it fits when the logic is a set of conditions that business owners can read and reason about.
The DMN standard comes from the Object Management Group, and the Flowable DMN docs describe it as the notation for decision logic. Of the DMN expression types, Flowable currently supports decision tables, so this is the expression type to plan around if you adopt the engine for rules. The docs also advise keeping one decision definition per file. That advice matters for ownership and review: each decision can then be versioned, deployed and tested on its own, and a change to one routing rule does not force a redeployment of unrelated decisions. Confirm the current list of supported expression types against the DMN introduction for the Flowable version you plan to run, since support may change between releases.
Moving rules out of code is a design decision, not only a packaging change. Decide which rules are stable enough to stay in delegates, which change often enough to justify a table, and who will own each table after go-live. Business analysts may draft tables, but developers still own the integration that passes inputs in and reads outputs back, and someone must own the test cases that prove a change behaves as intended. Before committing, check that your rules fit a table layout without becoming unreadable, because a decision table with dozens of columns is harder to govern than the code it replaced.
Which hit policy and table design fit each rule set
Some rule sets must return exactly one answer, such as an approval tier for a given amount and product. For these, the table must be designed so that no two rows can match the same inputs. The DMN standard, which the Object Management Group maintains, defines hit policies that control how matches are resolved, and the outcome you need determines which one fits. Verify the hit policy values that Flowable accepts in the Flowable DMN introduction before you design around them.
- Define cardinality first: Write down whether a single input set may ever match two rows. If the answer is no, the table should enforce it.
- Check for overlapping rows: Ranges such as 10,000 to 50,000 and 50,000 to 100,000 overlap at the boundary. Use exclusive bounds or explicit ranges.
- Plan the fallback row: Decide what happens when no row matches, and add a catch-all row only if the business rule allows a default outcome.
- Keep the output column count small: Each extra output column multiplies the cases your tests must cover.
Before release, confirm that every input combination in your test set returns one outcome and that boundary values land in the expected row.
Some decisions must return every rule that applies, such as all required checks for a customer onboarding case or all notification types triggered by an event. In this situation a first-match or unique policy would hide valid results. The DMN standard supports collecting all matching outputs and, for some collect variants, aggregating them. Confirm which collect and aggregation options your Flowable version supports, because the decision table documentation is the source for that list and support can differ by release.
- Decide the shape of the result: Determine whether the caller needs a list of outcomes, a count, or a single aggregated value. Each shape needs different downstream handling in the process or case.
- Make outputs comparable: If you aggregate numeric outputs, make sure every row uses the same unit and scale.
- Avoid duplicate outcomes: Two rows that return the same value will appear twice in a collected list unless your design removes duplicates upstream.
- Handle an empty result: Define what the calling process does when no rule matches, because a collected result can be empty without an error.
Before release, test a case with no matches, a case with one match and a case with several matches, and confirm the variable type the calling BPMN or CMMN element receives.
Some rule sets are written as a sequence of conditions where the first applicable rule should win, such as a discount policy that checks special cases before general ones. The Flowable DMN documentation shows a decision table declared with hitPolicy FIRST inside a DMN 1.1 definitions element, which is the pattern to start from for this situation. Ordering is part of the logic, so the row order in the file is a control, not a presentation detail. Confirm the ordering-based hit policies that your Flowable version accepts before you rely on them.
- Put exceptions above defaults: Place specific rules first and general rules last, and state that rule in the table's documentation.
- Record why each row sits where it does: A short description on each rule helps reviewers see whether a reorder changes behavior.
- Review order changes as logic changes: Treat a reordered row as a behavior change that needs its own test cases.
- Test the overlap zone: Build cases that match both an exception and a general rule to prove the exception wins.
When you review a table in version control, check that the diff shows row moves clearly, because a reordered file can look like a formatting change to someone who does not read the table.
The Flowable DMN documentation advises one decision definition per file. This keeps each decision independently versioned, deployed and reviewed, and it makes it clear which file changes when a rule changes. Input and output column names matter just as much, because they become the variable names that calling processes and cases read and write. A renamed column can break a BPMN or CMMN model that works in the engine but fails at runtime when it expects a variable that no longer exists.
- One decision per file: Keep each decision in its own DMN file, and name the file after the decision key so deployments are traceable.
- Stable column names: Choose input and output names once, and document them as an interface between teams.
- Consistent naming across models: Use the same variable names in the decision, the process variables and the test fixtures.
- Versioned change records: Tie each file change to a change record so auditors can see when a rule's inputs or outputs changed.
- Interface review on change: Require a review of the calling models whenever a column is added, removed or renamed.
Before release, confirm that every variable a calling model passes exists in the decision's input columns and that every output the model reads is produced by the decision.
The DMN standard defines several expression types for decisions, and Flowable currently supports decision tables among them. Models that depend on another expression type cannot be built as they would be in a fully featured DMN tool, so the design must stay within decision tables or move that logic into a delegate or expression elsewhere in the process. Confirm the current support status in the Flowable DMN documentation for your engine version, because this is the first constraint that changes a design, and it is easier to find before modeling starts.
- Inventory the logic before modeling: List each rule and check whether it fits a decision table or needs another expression type.
- Plan the alternative for unsupported logic: If a calculation does not fit a table, decide whether it belongs in a service task, a script under your security policy, or an upstream system.
- Confirm the import path: Ask the team that owns the models whether any existing DMN files come from another tool and need conversion.
- Document the decision boundary: Record which logic lives in tables and which lives in code, so future changes follow the same split.
Before committing to the design, run a short spike with one real rule that uses your most complex condition and confirm the engine evaluates it as expected.
How to set up DMN decisions in a Flowable project
This sequence takes a decision table from a dependency on the DMN engine to a tested, versioned rule that a process or case calls at runtime, so business rules live in a reviewable table instead of application code.
Add the DMN engine to the stack
The engineering team adds the Flowable DMN engine to the Java project, either through the individual DMN engine starter or through a broader starter, depending on which other engines the application already uses. Flowable's Spring Boot documentation describes starters for all engines, for REST, and for the process, CMMN and DMN engines individually, so confirm the starter matches the Spring Boot version your platform runs. The step is done when the application starts cleanly and the DMN engine is available to the context. Check the startup log and confirm the engine beans load without errors.
Author one decision per DMN file
Rule authors or developers create the decision table in a DMN file, with one decision definition per file, since Flowable's DMN documentation advises that layout. Decision tables are the expression type Flowable currently supports, so the table defines inputs, outputs and rules inside a DMN 1.1 definitions element, with a hit policy such as FIRST set on the table. Store the file in the same version control repository as the application so changes go through review. The step is done when the file parses and a reviewer can read each rule against its input columns.
Deploy the definition and confirm its version
The deployment pipeline or an administrator deploys the DMN file to the engine, and the engine assigns a version to the decision definition. Record the decision key and version number returned by the deployment so later runs can be traced to a specific rule set. Confirm the deployed version through the engine's repository query or the REST API, and check that the version matches the file committed to source control. The step is done when the deployed decision key and version match the release record.
Call the decision from a process or case task
A developer adds a business rule task in a BPMN process, or a decision task in a CMMN case, that references the decision key and maps the process or case variables to the decision inputs. Output columns are written back to process variables, so the next gateway or plan item can act on them. Keep input names stable, because a renamed variable breaks the mapping silently until a test or live run exposes it. The step is done when a test run of the process or case reaches the decision and writes the expected output variables.
Verify outputs for known inputs before release
The test team writes automated tests that execute the decision directly with a set of known input values and compare the returned outputs with the values the business owner signed off. Include cases that match one rule, cases that match none, and cases that match several, because the hit policy decides how overlapping rules behave. Run the tests in the build pipeline so a rule change that alters an output fails before it reaches an environment. The step is done when every signed-off input produces the expected output and the test suite runs on each change.
Promote the tested version and record it
The release owner promotes the tested DMN file through the same environments as the application, deploying it and confirming the version active in each environment. Record which decision version each process instance or case uses, so auditors and support staff can explain past outcomes. Plan how existing running instances will continue to use the rule, because a deployed decision change affects new evaluations and the team must decide how in-flight work is handled. The step is done when each environment reports the approved version and the release record links it to the test results.
Configuration options and when each fits
This table compares the four choices a team makes when it moves rules into Flowable DMN tables: how tables are authored, how they are grouped into files, how they are deployed, and where they are versioned. Read each row for the condition that favors an option and the cost it carries. The main takeaway is that the authoring and file-grouping choices are easy to change early and expensive to change after rules are in production.
| Decision | Option | When it fits | Trade-off |
|---|---|---|---|
| Authoring | DMN editor that writes the DMN XML | Business analysts or domain experts own the rules and need to review tables without reading XML | Confirm the editor's DMN 1.1 output and hit policy support with Flowable before adopting it |
| Authoring | Hand-written DMN XML | Engineers own the rules and want precise control over every attribute and diff | Reviewing rule changes with non-technical stakeholders takes more effort |
| File layout | One decision definition per file | Each table has its own owner, release cadence and test suite | Shared logic must be repeated or called across several decisions |
| File layout | Shared rules across several decisions | Several processes or cases depend on the same eligibility or pricing logic | A change to a shared table affects every caller, so regression testing scope grows |
| Deployment | Deployed through the Flowable engine API in your application | Your application already packages and releases process and decision definitions together | Each service that loads rules must include deployment code and handle failures |
| Deployment | Deployed through the Flowable REST application | Teams deploy rules independently of application code or use a shared engine | Access to the REST API must be secured, and deployment becomes an operational control |
| Version control | Tables stored in the same Git repository as the application | Rules and the code that calls them must change together and be reviewed as one unit | Rule changes wait for application release cycles unless you add a separate path |
| Version control | Tables stored in a dedicated rules repository | Rule owners release on their own schedule and need a separate approval trail | Teams must agree on which rule version each application build expects |
How versioning and deployment of rules change production risk
Decision tables change behavior without a code change, so the way they are versioned, deployed and rolled back matters as much as the table itself. The cards below cover the decisions that connect a DMN file in source control to the decision that a running process actually evaluates.
New deployment, new definition version
Deploying a DMN file to Flowable creates a new version of the decision definition under the same key. New evaluations after that point use the new version, so a deployment is a production change even when no BPMN or CMMN model changed. Check that your pipeline records which version each release deployed, and that the key stays stable across releases so callers keep resolving the decision.
Running instances and the version they keep
A process or case instance that already called a decision is not automatically re-evaluated against a new table. Confirm in the Flowable docs exactly which decision version each running instance resolves, and whether it resolves again at a later step. Test a long-running instance that crosses a deployment, because its outcome depends on that behavior.
Rule changes and process version changes
A new decision table and a new process definition can ship together but take effect at different times. A process that starts on version 2 may call a decision version that expects different input columns. Agree on a compatibility rule: keep input and output contracts stable, or deploy the decision and the process in one controlled release with a defined cutover.
Rollback by redeploying a known version
Rolling back a rule means deploying the previous table content again, which creates another new version rather than reactivating the old one. Keep the last known-good DMN file in source control, and rehearse the rollback in a non-production environment. Confirm how your team will identify which instances evaluated the bad version, since that set drives remediation.
DMN files in source control
Store one decision definition per file, as the Flowable docs advise, and review changes to hit policies, input expressions and output values like code. A reviewer should be able to see what changed in a rule, who approved it and which release carried it. Commit tests with the table so a rule change cannot merge without evidence.
Promotion between environments
Promote the same DMN artifact through development, test and production rather than editing tables in each environment. Keep environment-specific settings out of the file, and confirm the deployment pipeline checks the decision key and version after each promotion. Approval gates for production rule changes should be written down, with a named owner for business sign-off.
How to test decision tables before release
Treat each decision table as code that needs a regression suite before it reaches production. Build a fixed set of input cases, each with an expected output, that covers every rule in the table and every boundary value the inputs can take, such as the exact threshold where one rule hands over to the next. Keep the cases in version control next to the DMN file, so a change to a rule and the change to its expected results are reviewed together. Run the suite in your CI pipeline against the definition as it is deployed to a test engine, not against a copy of the XML, so that the parsing, deployment and input typing your process actually uses are exercised too.
Add structural checks that the case set cannot give you on its own. Under a multi-match hit policy, two rules that both match an input will return more than one result, and the case set will only reveal this if someone wrote a case that lands in the overlap. Scan the table for overlapping and missing input combinations under the hit policy you chose, and fail the build when a new rule creates an overlap or leaves a gap. Confirm with the Flowable DMN documentation which hit policy checks, if any, the engine performs at deployment and which you must write yourself, because the supplied material does not say.
Confirm the testing support before you choose a framework. The supplied sources do not name a test harness or API for evaluating decision tables, so check the Flowable DMN documentation for how to invoke a decision from a unit test and how to read its output, starting from the DMN introduction. Whatever mechanism you use, agree on who owns the expected outputs. Business owners should sign off on the case set alongside the rule change, because a suite that the engineering team wrote alone will test the table against the team's reading of the policy rather than the policy itself.
Limits to confirm in your Flowable environment
Flowable DMN decision tables work within limits that depend on the DMN expression types the engine supports, the DMN version the docs use, the Flowable release you run, and where your history and deployments are stored. Confirm each one against your own version and database before you commit rule logic to tables.
Decision tables are the only expression type
The Flowable DMN docs say that, of the DMN expression types, Flowable currently supports decision tables. Rules that you would model as literal expressions, function definitions or other DMN constructs need a different home, such as a Java delegate or an expression in the calling process. Inventory your rules and sort them by shape before you design the table layer, and confirm the current list of supported types against the version you plan to run.
DMN 1.1 in the documented examples
The Flowable DMN docs show decision tables declared inside a DMN 1.1 definitions element, and they advise one decision definition per file. Ask your architects whether your authoring tool exports DMN 1.1 or a later version, and confirm that the engine accepts the exported XML. Mismatched namespaces or unsupported elements tend to surface at deployment, so test an export and import early.
Version-specific Spring and Java baseline
Flowable 8.0.0 was released on February 27, 2026, and its release notes describe an upgrade to Spring Framework 7 and Spring Boot 4, with no backward compatibility for Spring Boot 3. Flowable 7.x moved to Java 17, Spring Boot 3 and Jakarta EE. Pick the release line that matches your application stack first, because the DMN engine comes with the same baseline as the rest of the platform.
Supported databases for deployments and history
The Flowable configuration docs list H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server as supported database types. Deployed DMN definitions and decision history are stored in these databases, so your chosen engine must be one of them. The docs also note that MySQL versions below 5.6.4 lack millisecond precision, which affects audit timestamps on decision evaluations. Confirm your database version before you enable history.
Editor and modeling tooling gaps
The open-source engine provides Java and REST APIs for deploying and evaluating decisions, but visual debugging, low-code modeling and governance features are part of Flowable's commercial products. Confirm which decision table editor your business analysts will use, how exported files reach the repository, and who reviews tables before deployment. Plan for any gap with a tested review step in your pipeline rather than assuming the open-source tools cover it.
Questions teams ask before moving rules into DMN tables
What does a DMN decision table implementation cost, and what drives it?
The cost depends mainly on how many decisions you are moving, how many rules each contains, and how much of the logic is currently spread across code paths, spreadsheets and approvals. Flowable's open source engines are licensed under Apache 2.0, so the software itself carries no license fee. The paid components are the people: analysts who document the current rules, engineers who wire decisions into processes and cases, and testers who prove the tables behave as the business expects. Ask any quote to break out discovery, table build, integration, test cases and handover as separate line items, and to state which parts recur, such as rule changes after go-live. DeployOpen does not publish a price list, and a quote follows from the written scope.
How long does moving a rule set into Flowable take?
Duration follows from the number of decisions, the number of callers, and how well the current rules are documented. A single decision table with clear inputs and outputs moves far faster than a set of rules embedded in several services with unclear ownership. The main variables are:
- How many rules exist and how often they change
- Whether the business has signed off on the current behavior
- How many BPMN processes and CMMN cases call each decision
- How much of the surrounding test data already exists
The engagement is fixed-scope, so the timeline is agreed in writing before work starts and should be tied to the decision list and deliverables.
What does the work need from our business analysts and developers?
Business analysts own the rule meaning. They need to confirm inputs, outputs, the order of rules, and which cases are exceptions, and they must review the test scenarios that show expected results. Developers own the integration: they decide how process variables map to decision inputs, how a BPMN or CMMN task calls the decision, and how the result is written back. Your team should also agree who is allowed to change a table after release, because a table edit is a behavior change even though no code changed. Plan time for both groups in the scope, since a rule set without a named business owner tends to stall during review.
Can our own team implement DMN decision tables without a partner?
Yes, a team with Java and Flowable experience can build DMN decision tables in-house, because the engine is open source and the DMN docs describe decision tables and hit policies such as hitPolicy FIRST. The skills gap is usually not the XML but the rule design: choosing a hit policy, avoiding overlapping rules, and keeping one decision definition per file. Teams often start in-house for a pilot decision and bring in outside help for the larger rule set or for the CI pipeline that tests and deploys tables. Ask yourself whether anyone on the team can own rule changes after handover, since that ownership is the part that recurs.
How do we test decision rules without a full production environment?
Test decision tables as units before they reach a running process. Each table can be executed with a set of input cases that cover every rule, every boundary value, and the default output when no rule matches. Store these cases in version control next to the DMN file so that every change runs them automatically. Use an in-memory or containerized database for these tests, since the engine supports H2 alongside production databases such as PostgreSQL. Keep a separate set of end-to-end tests for the BPMN and CMMN callers, which confirms that variables reach the decision and that the result drives the right path.
How do rule changes affect cases and processes that are already running?
A deployed decision version is used when a decision is evaluated, so a new table version affects new evaluations after deployment. Work already in flight may evaluate the decision later, at which point it picks up the new rules. Before release, identify which running instances will reach a decision call after the change and decide whether that is acceptable. If it is not, plan a release that avoids long-lived instances on old behavior, or plan process instance migration for affected work. Record which decision version each case used, so that auditors and support staff can explain a past outcome.
What should we confirm about DMN support in the Flowable version we choose?
Confirm the DMN feature set and the Flowable release line against your own requirements before you commit. The current Flowable DMN docs say DMN is an Object Management Group standard and that decision tables are the expression type Flowable supports today, so any other DMN expression type needs separate verification. Check the release notes for the version you plan to run, since Flowable 8.0.0 changed the Spring and Jackson baseline. Ask for a short proof of concept that runs one real decision end to end on your database and your Spring or servlet setup before you finalize the scope.
How DeployOpen scopes and delivers Flowable decision tables
Every Flowable decision table engagement starts with a written scope, and DeployOpen agrees that scope, the deliverables and the timeline with you before any build work begins. For this topic, the scope should list which business rules move out of code, which BPMN and CMMN models call them, which decision tables are in and out, and which hit policies each table uses. DeployOpen plans and implements inside your own infrastructure, whether that is your cloud accounts, your data centers or an air-gapped network, so the deployment, the rule repository and the test environment stay under your control. DeployOpen does not publish a price list. A quote follows from the written scope, so the more precisely the rules and call sites are listed, the more precisely the quote can reflect the work.
Table design is where most of the effort sits, and it needs your domain experts in the room. DeployOpen works with the people who own the underwriting, eligibility or pricing rules to define inputs, outputs, rule ordering and the hit policy for each table, then encodes those decisions as one decision definition per file in the DMN 1.1 format the Flowable docs describe. On the process side, the agreed scope also covers how each BPMN or CMMN model calls its decisions, how the input variables are mapped, and how the decision results are routed back into the flow. The Flowable DMN introduction is the natural starting reference for your architects reviewing this design. Ask your domain experts to sign off each table against a set of worked examples before any integration work starts.
Each engagement includes a test suite that runs every decision table against expected inputs and outputs, including boundary cases and rule overlaps, so that a changed row or a new hit policy fails a build before it reaches production. Ongoing rule changes and Flowable version upgrades can be covered by an optional retainer, which suits teams whose rules change every quarter or who need a planned upgrade path. Ask DeployOpen to state in writing what a retainer covers, how change requests are prioritized, and how the test suite is extended for each change. Confirm with your own security and change management teams how rule changes will be approved and recorded before the first table goes live.
