Flowable DMN decision history and audit

Which DMN decision history Flowable records and when you need it

A regulated team often has to answer one question long after a decision was made: which rule produced this outcome, and on which version of the rules? Flowable's DMN engine can keep an execution history of decision evaluations, so the answer does not depend on someone remembering what the table said that day. Before you rely on it, confirm in the Flowable 8.x configuration docs exactly what the DMN history records, such as decision identifiers, versions, inputs, matched rules and outputs, and where those records are written. Do not assume a field exists because a neighboring history feature has it. The history is only evidence if you can show it was complete for the period in question, so treat its configuration as a control decision you record and defend.

Keep decision history when a past outcome may be challenged or when a process behaved unexpectedly and you need to see which rule fired. Credit, eligibility, pricing and claims decisions are typical candidates, because an auditor or customer may ask why a result was reached months after the rule changed. Troubleshooting is the other case: a routing decision that sent work to the wrong queue is far easier to explain from recorded evaluations than from reconstructed inputs. The cost is database load. Every recorded evaluation adds rows, and a decision called on every transaction writes far more than one invoked in a monthly batch. Estimate evaluation volume for each decision before you choose, and treat the trade-off between evidence and storage as a decision made table by table.

Make the choice per decision table. For each one, write down the business question it answers, how long you must be able to reproduce its outcomes, and the volume it reaches in production. Then measure table growth, write latency and the effect on your backup window in a staging environment with production-like volume. If the Flowable 8 release you target offers a switch to turn off DMN history persistence, confirm which decisions it applies to, whether it is global, and what evidence you lose while it is off. Then decide whether another record, such as application logs written when your process calls the decision, covers the gap. Supported databases are listed in the Flowable configuration docs, so confirm storage behavior on your database before you size it.

Which history setting fits audit, troubleshooting or high-volume decisions

This table compares three ways to set DMN history in Flowable: full audit evidence, troubleshooting history in lower environments, and disabled persistence for high-volume decisions. Read each row for what is recorded, what the team gives up, and what to confirm in the Flowable version you run. The main takeaway is that the option to disable DMN history persistence is part of the Flowable 8.0.0 release of February 27, 2026, so earlier versions need a different plan.

Setting	What is recorded	What the team gives up	What to confirm in your Flowable version
Full DMN history for audit evidence	Decision executions with inputs and matched outputs, retained in the history store for the period your policy requires	Storage growth and some database load on every decision evaluation, plus a retention job you must design and run	Confirm that DMN history is enabled, which tables hold it, and how your backup and retention process covers them
History for troubleshooting only in lower environments	Decision executions kept long enough for testers and developers to reproduce a rule outcome, usually with shorter retention	Assurance that the same records exist in production, so test evidence cannot stand in for production audit trails	Confirm the history setting in each environment's configuration and that lower-environment data is not copied to production stores
Disabled for high-volume decisions already logged elsewhere	No DMN execution records in the Flowable history store, so the decision inputs and outputs must come from your own application or logs	Built-in query of past rule outcomes in Flowable, and the ability to explain a historical result from the engine alone	Confirm that the option to disable DMN history persistence exists in Flowable 8.0.0 (released February 27, 2026) and is absent from earlier releases you may run
Decision logging in your own application	Inputs, decision key, version and output written by the calling process or service to your log or event platform	Engine-side consistency, since the application must capture the same data for every call path, including REST calls	Confirm which decision version was used, how the application records it, and that the log store meets your retention rules
Process history that still runs	Process and task history governed separately from DMN history, depending on your history level configuration	Assumes that process history alone can explain a rule decision, which it may not show in full	Confirm the history level setting for your engine version and test that a sample decision can be traced end to end
Storage and query cost for full history	Growth in history tables proportional to decision volume and the number of decision tables evaluated per transaction	Predictable database size unless retention is enforced, which adds ongoing operational work	Ask your team to measure row growth in a staging copy with production-like volume before choosing the setting

How to set up decision history in Flowable step by step

This sequence takes a team from confirming its Flowable and database baseline to proving that DMN decision executions are recorded, retained and backed up as the audit and troubleshooting trail the business expects.

Confirm the Flowable and Spring Boot baseline
The platform engineering lead checks which Flowable line the application runs. Flowable 8.0.0 was released on February 27, 2026, and it moved to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3, so a Spring Boot 3 application needs a planned upgrade or stays on Flowable 7.x. Record the Flowable version, Spring Boot version and JSON library in the project's dependency list. Done means every engine JAR and starter in the build resolves to one Flowable release and the Spring Boot version matches the release notes for that line.
Confirm the database type and its support status
The database administrator confirms which database the Flowable history tables will live in. The Flowable configuration docs list H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server as supported types, and they note that MySQL versions below 5.6.4 lack millisecond precision, which matters when auditors compare timestamps. Confirm the exact database version against your Flowable release and record it. Done means a signed-off database type and version appear in the design record, and a test instance of that database starts the engine with the schema created.
Decide the history level for each decision set
The business owner and the architect agree which decision tables need a persisted execution record. Work through each decision definition and classify it by audit need, troubleshooting value and expected execution volume. Decisions tied to customer outcomes or regulated approvals usually need a record, while high-frequency internal lookups may not. Confirm the classification with the compliance lead before configuration starts. Done means a written list maps each decision key to a history decision, and the list is stored with the deployment documentation.
Configure DMN history through the documented setting
The Flowable engineer sets the DMN history behavior using the configuration key named in the Flowable documentation for the release in use, applied at the engine configuration level in the Spring Boot properties or Java configuration. Confirm the exact key name and its accepted values in the release documentation, because the option to disable DMN history persistence is specific to Flowable 8. Avoid setting it globally if the classification in the previous step requires some decisions to be recorded and others not. Done means the configuration is in version control, and the application log at startup shows the chosen setting when the engine initializes.
Run a test execution and verify history rows
The test engineer deploys a sample decision table to a non-production environment, executes it through a process or direct decision call with known inputs, and queries the history tables in the database. Confirm that one record exists per execution with the decision key, version, inputs and outputs. Repeat with a decision marked as not recorded to confirm the setting behaves as configured. Done means the query results match the expected rows for both recorded and unrecorded decisions, and the results are attached to the change ticket.
Verify retention and growth of history data
The database administrator and the business owner agree how long decision history is kept and how the tables are pruned or archived. Measure row growth from the test run and project it against the expected production execution volume from the classification step. Ask the vendor or the Flowable documentation for the supported cleanup approach for history tables in your release, and do not delete rows directly without a tested procedure. Done means a written retention rule exists, with an owner and a review date, and the growth projection is signed off by operations.
Verify backup and restore of decision history
The operations engineer confirms that the database backups include the Flowable history schema and that a restore is tested. Restore the backup into a separate environment, start the Flowable engine against it and query a known decision execution from the test run. Also confirm that the audit team can read the history without access to the runtime data they do not need. Done means a restore test has returned the expected decision history rows, and the procedure, owner and frequency are recorded in the operations runbook.

Audit trail versus troubleshooting trail: what each needs

Compliance and audit teams need a complete, retained record of what each decision received and which rule matched. Their questions are usually reconstructive: for a given customer, case or date, what did the system decide, and on which inputs? The record must therefore cover inputs, matched rules and outputs, and it must survive the normal lifecycle of the process data beside it.

Retention tied to the control: Set the retention period from your record-keeping requirement, not from database housekeeping. Decision records can outlive the process instances they describe, so confirm how any cleanup job treats them.
Full input and match evidence: Auditors typically ask which rule fired and what values it saw. Run a test decision and confirm the record contains both before you rely on it.
Stable correlation keys: Records should link to the process instance, the case instance, the decision key and the deployed version. Without the version, a later rule change makes older evidence ambiguous.
Restricted and logged access: Inputs often contain personal data. Limit read access to named roles and log those reads where your policy requires it.
Integrity expectations: Ask who can edit or delete records through direct database access, and whether your auditors expect a copy kept outside the engine schema.

Confirm these points with your compliance lead and auditors before any history setting changes.

Storage trade-offs for high-volume decisions

History volume grows with decision executions, not with the number of deployed rules. A decision table can sit unused for months and write nothing, while a single decision called on every item in a batch writes one record per call. If a decision is invoked inside a loop, from a multi-instance activity, or from many process definitions at once, each invocation multiplies the writes. Before you choose a setting, count executions per hour at peak and per day, not the number of DMN files in the repository. Ask your team which processes call each decision and how often, because the most expensive decision is often one that was added as a shared helper.

Database cost is driven by five factors you can change. The first is write rate, meaning executions per second at peak. The second is row size, which depends on how many input and output variables each execution records, so wide decisions with large text or JSON values cost more. The third is retention period, since history that is kept for years accumulates in the same tables that the engine queries. The fourth is indexes, which speed audit queries but slow inserts and add storage. The fifth is backup size, because every retained record is copied into each backup and restore test. Ask the database team to confirm how backups and point-in-time recovery scale with your retention choice before you commit to it.

Audit queries also depend on timestamp precision and the database you run. Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server, and its configuration documentation notes that MySQL versions below 5.6.4 lack millisecond precision. If your auditors order decisions by time, confirm that the timestamp column in your chosen database keeps the precision your queries need, and test ordering with rapid consecutive executions. Check the Flowable configuration documentation for the exact version notes that apply to your database before you rely on them. Finally, run a load test with representative decision volume, variable sizes and retention settings, and measure insert latency, table growth and backup duration. Use those results, not general estimates, to decide between keeping full history, reducing what is recorded, or disabling persistence for high-volume decisions.

Protecting decision history as audit evidence

Decision history is only useful as evidence if the people and systems around it are controlled. The engine records which rules fired, but it does not decide who may read those outcomes, what happens to personal data in inputs, or how long records live. The cards below cover the parallel controls that make the history defensible, and each one sits in the application, database, logging or backup layer that you own.

Restrict who reads history

Decision history can be read through the Flowable REST API and directly from the history tables in the database. Flowable does not enforce business authorization on who may see a decision outcome, so the application or the REST gateway must decide which callers can query historic decision instances. Check that the REST application is reachable only from approved networks, that service accounts are scoped to the decisions they need, and that database read access to the history tables is granted through the same role model. Test each path separately, because a locked-down API does not protect a readable reporting schema.

Protect inputs containing personal data

Decision inputs are often copied from the process or case variables, so a history record can contain applicant names, identifiers, income or health details that were never meant to be stored in a second place. Map each input column to a data classification before you enable history, and decide which inputs should be omitted, pseudonymized or passed as references to a protected record. Ask your privacy lead to confirm whether a decision outcome counts as personal data in your jurisdiction, since the answer changes how long you can keep it.

Keep history out of shared logs

Engine and application logs are often copied to central log platforms with wide access, and a debug setting can write decision inputs and outputs into them. Review the logging configuration for the decision engine and the surrounding services, confirm that DMN execution details are not logged at debug level in production, and check that any log shipper applies the same access rules as the database. Logs that reach a broad audience can expose the same data your history controls protect.

Set retention and deletion rules

Audit evidence needs a defined lifetime, and so does personal data inside it. Agree retention periods with compliance and legal owners for decision history, then implement them as a scheduled job or database partitioning that removes or archives records on that schedule. Confirm that deletion also reaches the copies of inputs in logs, exports and reports, not only the history tables. Document the rule so an auditor can see both what is kept and why older records are gone.

Protect history backups

Backups of the history tables carry the same sensitivity as the live database, and they often outlive the retention rule because they are kept for disaster recovery. Encrypt backups at rest, restrict restore rights to named operators, and record who restores data and when. Test that a restored environment respects the same access controls, and confirm with your backup vendor or platform team how expired records are removed from backup sets. Otherwise a deletion that looks complete in production may not be complete in practice.

Questions teams ask before they set up decision history

How much effort does setting up DMN decision history take?

The effort depends mainly on how many decision tables are in scope, how many environments need the setting, and how much evidence auditors or troubleshooting teams expect to see. The engine change itself is usually small. The surrounding work takes longer: agreeing which decisions must be recorded, confirming what each record contains, testing that rules fire as expected, and documenting the result. Costs fall into two groups. One-time work covers design, configuration and verification. Recurring work covers storage growth, retention jobs and review whenever decision tables change. Ask any partner to split the quote into these groups and to name who performs each task.

How long does a typical decision history setup take?

The duration depends on scope and environment, and no fixed figure applies to every team. A setup with a few decisions, one environment and quick database access moves faster than one with many decisions, separate development, test and production databases, and several approval gates. Other factors include existing audit requirements and whether the team already runs automated tests for decision tables. Ask for the timeline in the written scope, with milestones for design sign-off, configuration in each environment, verification and handover. Confirm the Flowable version in use first, because the history option and its defaults should be checked against that version's documentation before work starts.

What must our team provide before the work starts?

Most of the inputs come from your side of the engagement. Plan to provide:

The DMN files in scope, the process or case models that call them, and the Flowable version deployed in each environment.
Read and write access to the engine database in each environment, plus a database administrator contact for schema and storage questions.
Written retention rules that state how long decision records must be kept and who may delete them.
Audit requirements from internal audit, compliance or the relevant regulator, including the questions the records must be able to answer.

A non-production environment is also needed so that changes can be tested before they reach production data.

Can an internal team set up decision history without a partner?

Yes, a team with Java, Flowable and database administration skills can usually complete the configuration on its own, because most of the work is configuration, verification and documentation. Gaps tend to appear in audit interpretation, storage sizing, testing rule behavior across different hit policies, and packaging evidence for reviewers. Internal teams also often underestimate how long reviews take. The decision depends on skills and spare capacity. A partner can take on scope definition, configuration in each environment, verification and the runbook, while your team keeps ownership of the decision logic and retention rules. Either way, check the configuration against the Flowable documentation for your version before you rely on it.

What happens to existing data when we change the history setting?

In most setups, a change to the history setting affects only executions that happen after the change, but confirm this for your Flowable version. Turning persistence off stops new records from being written, while existing records stay in the database until your own retention process removes them. Turning persistence on starts recording from that point and does not rebuild records for past executions. Flowable 7.0.0 removed async history, so do not assume history behaves the same way across major versions. Read the Flowable configuration docs for your version, test the change in a copy of production data, and agree in writing what happens to historical records.

What should we ask for in a written scope?

Ask for a scope that names each decision in scope and the history fields recorded for it, along with the Flowable version and configuration for every environment. The scope should describe how storage growth will be estimated, how retention jobs are designed and who runs them. Verification steps should show that records exist for each hit policy in use, and the handover should include a runbook and a list of exclusions. DeployOpen plans most engagements as fixed scope, so deliverables and timelines are agreed in writing before work starts. Compare quotes by checking whether each one covers the same decisions, environments and acceptance criteria.

Limits to confirm in your environment before you rely on decision history

Decision history is only useful for audit and troubleshooting if you know exactly what the engine stores, for how long, and at what cost. Each item below should be confirmed against the Flowable documentation for your exact version and then tested in your own environment, not assumed from general descriptions of the engine.

Exact setting name and default

Confirm the precise configuration key that controls DMN history persistence in the Flowable version you run, and whether it is enabled or disabled by default. Flowable 8.0.0 introduced an option to disable DMN history persistence, but the key name, its default and its location in the configuration should be read from the release notes and configuration docs for your release. Record the value your environment actually resolves at startup, since a value set in one layer can be overridden in another.

Global or per-decision control

Find out whether history can be switched on or off for individual decision tables or only globally for the engine. Per-decision control changes how you separate high-value audit decisions from high-volume routing decisions, while a global switch forces one policy across all rules. Ask the vendor or test in a sandbox which level applies, and confirm that a decision you exclude does not leave partial records that confuse later investigations.

Behavior for already executed decisions

Test what happens to decision executions that ran before the setting was changed. Confirm whether records already stored remain readable, whether turning history off removes or hides existing rows, and whether a change applies to in-flight process instances. Your audit trail depends on these answers, so document the behavior for each transition, including a change made during a release window.

Database and write volume

Confirm that your chosen database type and version can absorb the insert rate of decision history at peak load. High-volume decisions called inside busy processes can add a row per execution, and the cost lands on the same database that runs process history and the async executor. Load test with realistic rule counts and call frequency, and watch lock contention, table growth and index size before committing to full history.

Retention and audit obligations

Map your own retention periods, access rules and evidence requirements onto the data the engine actually stores. The engine does not decide how long records must be kept or who may read them, so you need a documented retention schedule, a purge or archive process that the engine's tables support, and a check that the stored fields capture the inputs and outputs your auditors ask about. Agree this mapping with compliance owners before relying on history as evidence.

How DeployOpen scopes and delivers Flowable decision history

DeployOpen approaches Flowable DMN decision history as a written scope before any configuration changes. We agree which decisions must leave an audit trail, how long that record is kept, and where it is stored, then build and hand over the setup inside your own infrastructure.

How we scope

Inventory the DMN decisions in scope and state which ones need an execution record for audit or troubleshooting.
Confirm the Flowable engine version and the supported database type where history will be stored.
Agree in writing whether the history setting is enabled, disabled or varies by decision, with the reasons for each choice.

How we build

Configure the DMN history setting and database schema in a non-production environment first.
Estimate storage growth from expected decision volumes and test retention and purge settings against that estimate.
Test that a sample decision execution writes the expected history record, including inputs, outputs and the rule that matched.

How we hand over

Document which decisions write history, where the records are stored and who can query them.
Provide a runbook for purging, backing up and restoring history tables, with the steps your team will run.
Walk through the audit queries and troubleshooting checks with the engineers and compliance staff who will use them.

How we support

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
Ongoing support, Flowable upgrades and continuous testing are available as a retainer.
Revisit history settings during Flowable version upgrades, since storage and schema behavior can change between releases.