Open source case management with CMMN for unstructured regulated work
CMMN fits claims, investigations, complaints and permit work, where the next step depends on a handler's judgment rather than a fixed sequence. Flowable, licensed under Apache-2.0, executes CMMN alongside BPMN and DMN, with Java and REST APIs. Operaton, an Apache-2.0 fork of the Camunda 7 codebase, is built as a BPMN 2.0 engine. Its 2.1 release notes list CMMN 1.1 compliance, but a case type that depends on sentries, discretionary tasks and milestones should not be assumed to behave the same way until a proof of concept has run it. Ask the Operaton project and your partner to demonstrate that case type on the engine you select.
The difference from an ordinary BPMN approval is the shape of the work. A BPMN model draws the path from start to end. A CMMN case plan holds a case file of documents and data, a set of tasks that become available when entry criteria (sentries) are met, and milestones that record progress. A handler can add a discretionary task the model did not foresee, and the case closes when its exit criteria are met. Deadlines set by statute or regulation are usually best modeled as timers and milestones tied to the case, so an overdue step is visible to the supervisor. The engine choice follows the case type, not the whole organization: a complaint process may need CMMN, while a fixed payment approval beside it stays in BPMN.
Before you commit, list each case type and mark which steps are fixed, which are at the handler's discretion, and which carry a legal deadline. Decide what the case file contains and where documents are stored, because Flowable 7.0.0 removed the form and content engines, so forms, document storage and the task interface are built by your team or partner. Confirm how Flowable's history tables keep the audit trail of who added a discretionary task, which sentry fired and when, and set a retention period that matches your records rules. Those answers shape the case model more than the choice of engine does. The Flowable open source page lists the engines and their licensing for your review.
Which requirements shape a CMMN build in a regulated organization
This table maps the requirements that most often shape a CMMN case build to the regulation or internal control behind each one, and to what that means for the build. Read each row as a question to settle with counsel, internal audit and the business owner before the design is fixed. The main takeaway is that audit history, retention and segregation of duties are design decisions, and they are much cheaper to make at the start than to retrofit.
| Requirement | Likely source of the requirement | What it means for the build |
|---|---|---|
| Complete per-case audit history | Internal control and records expectations; confirm with internal audit and counsel | Log every case creation, stage change, task claim, decision and document upload with user, time and reason. Keep history separate from mutable case data so it can be reviewed later. |
| Retention of case files and task history | Sector records rules and retention schedules; confirm the applicable period with counsel | Define retention per case type and trigger. Plan deletion or archiving for running cases as well as closed ones, and test that the engine history tables can be exported and restored. |
| Role-based task assignment | Access control expectations under internal policy and sector rules | Map case roles and task candidate groups to the identity directory. Confirm how the engine resolves roles at runtime, since identity integration is usually replaced or extended in a build. |
| Deadlines, reminders and escalation | Statutory or service-level deadlines set by the business or regulator; confirm each one with the owner | Use CMMN timers and milestones for each deadline. Test how timers behave across restarts and multi-node clusters, and document who receives each escalation. |
| Segregation of duties on decisions | Internal control design, such as approval limits and four-eyes review | Prevent the same user from preparing and approving a decision in the same case. Enforce this in task assignment rules, not only in the user interface. |
| Data residency and personal data in case variables | Data protection law and internal data classification; confirm with the privacy office | Keep case files and variables in the organization's own databases and object storage. Limit personal data in case variables and reference documents instead of copying them. |
| Automated decisions or AI assistance in case handling | EU AI Act Articles 12 and 19 apply only if the system is high-risk; confirm applicability with counsel | If an AI component suggests or makes case decisions, record its inputs, outputs and version as events, and keep those logs for the period counsel confirms. |
| Change control on case models | Internal change management and testing expectations for the platform | Version case models, test them before promotion, and record which model version governed each open case so running cases are not silently changed. |
Which open-source engines execute CMMN and when each fits
CMMN work is executed by engines that differ in license, governance and how far their CMMN support goes. The options below are the ones to shortlist for claims, investigations and permits, and each card names the check that should settle the choice before a build starts.
Flowable as the CMMN-capable engine
Flowable is an Apache-2.0 engine set that provides BPMN process execution, CMMN case management and DMN decision rules, with Java and REST APIs in one platform. For case work, it means case plans, stages and human tasks can sit next to BPMN processes that handle the deterministic steps, such as document intake or payment release. Check which CMMN features your case types need, such as milestones, sentries and discretionary items, and test them against the version you plan to run.
Flowable 8.0.0 platform baseline
Flowable 8.0.0 was released on February 27, 2026. Its release notes describe an upgrade to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3, and Jackson 3 as the default JSON library. Teams with existing Spring Boot 3 applications should plan that upgrade as part of any CMMN build, and confirm with Flowable how the CMMN engine behaves on the version they select.
Commercial Flowable products on the same engines
Flowable's commercial products, including Flowable Work, Engage, Orchestrate and Design, are built on the same engines and add low-code modeling, visual debugging, security controls, monitoring and governance. Open-source users get a community forum, while professional services and partners are offered separately. Decide early whether case designers need a visual modeler, because building one on the open-source engine is a separate cost line from the engine itself.
Operaton as a Camunda 7 successor
Operaton is an Apache-2.0 BPMN 2.0 engine forked from Camunda 7 CE, created after that edition reached end of life in October 2025. Its 2.1 release notes list BPMN 2.0, DMN 1.3 and CMMN 1.1 compliance and state API compatibility with Camunda 7 CE 7.24. Confirm that Operaton's CMMN execution covers your case plan patterns, since its strongest maturity is in the BPMN lineage it inherited.
Governance and support model for Operaton
Operaton is maintained by an open-source community with no single company in control, and its FAQ says governance is still forming, with plans for a non-profit organization. It has no open-core model, and support comes from several independent providers. It releases feature versions in April and October, each supported for six months, with no traditional LTS line. Budget for a planned upgrade cadence and an internal or partner owner who can absorb that rhythm.
Camunda 8 licensing as a constraint
Camunda 8 source code is under the Camunda License 1.0, which permits use only in non-production environments without a commercial license. A case platform built on it therefore needs a commercial agreement before production go-live, and that cost and its terms should be confirmed in writing before comparing it with the Apache-2.0 options. Treat this as a procurement constraint to resolve early, not as a technical comparison.
How case data, tasks and audit history are kept
Keep three kinds of data apart from the start: the case file (claim documents, complaint correspondence, permit drawings, investigation notes), the task records the engine creates for each human action, and the engine history that records what happened and when. The engine owns the last two. The case file usually belongs to a document store, a records system or an object store that your team already governs. Decide which system is the system of record for each item before modeling, because it determines who can edit what, how long each part is retained and what an auditor will be shown. Flowable's CMMN engine persists case instances, plan items and human tasks in a relational database, and it exposes them through Java and REST APIs, so the case file itself should be referenced from case variables rather than copied into them.
The database choice is the first infrastructure decision. Flowable's configuration documentation lists H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server as supported database types, and notes that MySQL versions below 5.6.4 lack millisecond precision, which matters for ordering audit entries. Operaton 2.1's release notes set minimum versions of PostgreSQL 14, MariaDB 10.11 and MySQL 8.4, with Oracle 21, SQL Server 2022 and DB2 support unchanged. Confirm the exact versions with the vendor before you commit, and ask your partner which engine history level is enabled by default, how long history rows are kept and whether a purge job is configured. Audit history is only as complete as those settings, and the content of the document store determines whether a reviewer can reconstruct what a case officer saw when they decided.
Two questions decide whether the audit trail will satisfy a regulator or internal auditor: where attachments live, and what retention applies to each store. If attachments sit in the database, backups, replication and retention jobs cover them automatically, but the database grows quickly. If they sit in object storage, you need versioning, legal hold and deletion logs in that store, and the case record must reference the exact object version. Ask for a written retention schedule that covers engine history, task records, case variables and attachments separately, and test a restore of one closed case, including its task timeline and attached evidence, before go-live. Document which roles can read history, which can purge it, and how the purge itself is logged.
Deployment choices for case data that cannot leave the organization
Running the engine in your own data center keeps case records, task history and attached documents on hardware you operate, and it gives the security team direct control over network paths and storage encryption. The engine is a Java application, so it can run on servers, virtual machines or a Kubernetes cluster you already manage. Flowable's open source engines can be embedded in a Spring application or run through its REST application, which lets you choose the deployment shape your platform team already supports.
- Database placement: Place the case database on the same network zone as the engine, with PostgreSQL 14 or later on your own storage. Confirm which databases the chosen engine supports and which minimum versions apply.
- Backup and restore: Take database backups that are consistent with the engine's state, because running cases, timers and pending human tasks live in the database. Rehearse a restore into a separate environment and confirm the case state after recovery.
- Identity integration: Connect the engine to your directory through the identity service the engine documents, using LDAP or a custom implementation. Confirm how role and group mappings for case roles are maintained.
- Upgrade paths: Flowable 8.0.0 moved to Spring Framework 7 and Spring Boot 4 and has no backward compatibility for Spring Boot 3, so an application on Spring Boot 3 needs a planned migration before upgrading.
Confirm the upgrade path with the vendor and your partner before you commit to a version, because the framework change affects your application code, not only the engine binaries.
In a customer cloud account, the engine and database run in subscriptions or projects that your organization owns and administers, not in a vendor's multi-tenant service. Data residency is then set by the region and the account controls you choose, and encryption keys can be managed in your own key service. The operating model shifts toward infrastructure-as-code, container images and managed database services, which must be checked against your data classification rules.
- Database placement: Decide between a self-managed database in your cluster and a managed PostgreSQL service in the same region. Confirm that the managed option meets the minimum database versions required by your engine release.
- Backup and restore: Use the cloud provider's snapshot and point-in-time features alongside an engine-consistent backup, and store copies in a separate account or region if your recovery targets require it. Test restores of running cases, not only empty databases.
- Identity integration: Federate your corporate identity provider into the cloud account for administrators and connect the engine to the same directory for case roles, so access revocation applies in both places.
- Upgrade paths: Operaton publishes half-yearly feature releases in April and October with monthly patch releases. Each major or minor version is supported for 6 months until the next one ships, and there is no traditional LTS line. Confirm whether that window fits your patch policy, or plan to run a supported patch level with your own backport process.
Check whether the cloud provider's managed services and your data residency rules allow the chosen engine and database to run in the target region.
An air-gapped deployment has no route to the internet or to vendor-hosted services, so every component, container image, model file and patch must be transferred in through an approved process. Case data stays inside the isolated network, which suits claims, investigation and public sector files, but every dependency becomes your responsibility to mirror and verify. Build and test the deployment bundle outside the enclosed network before any transfer.
- Database placement: Keep the database inside the enclosed zone with no external replication. Confirm that the database engine, drivers and any extensions can be installed from your internal mirror.
- Backup and restore: Store backups on media or storage inside the enclosure and define how they are verified and restored after a transfer review. Record each backup set and the engine version that wrote it.
- Identity integration: Use an internal directory service only. Avoid federation paths that depend on external identity providers, and document how emergency access is granted and removed.
- Upgrade paths: Each release must be built, scanned and tested outside the network, then imported with its checksums and release notes. Operaton 2.1 requires Java 17 and is tested on Java 17, 21 and 25, so confirm the JDK you can mirror and support.
Ask your partner how the transfer process, dependency mirror and patch cadence will be documented, and whether the six-month support window per version works with your change approval cycle.
How a CMMN rollout moves from one case type to production
This sequence takes one case type from a mapped process to a monitored production service, with each phase closing on a signed artifact or recorded evidence. It keeps the human decision points and the audit trail in view from the first workshop to the cutover.
Select the first case type and map it
The process owner, a case worker and the engineering lead choose one case type with a clear human decision at its center, such as a complaint that needs investigation, a permit application or an insurance claim. The team maps its stages, milestones, discretionary tasks, mandatory tasks, entry and exit criteria, and the deadlines that regulators or customers impose. Output: a signed case scope document listing in-scope variants, out-of-scope exceptions and the named decision owner for each stage.
Model the case and its decision points
The engineering team models the case in CMMN, using stages, planning tables, milestones and sentries to express when work becomes available and when it is complete. Where a decision follows a fixed policy, the team separates that logic into a decision table (DMN) rather than hard-coding it into the case. Business owners review the model against the scope document and sign it off. Output: a versioned, signed case model with a decision inventory and an open-issues log.
Build the task UI and integrations
The team builds the work queues, forms and case views that caseworkers use to claim, complete and escalate discretionary tasks, and connects the case to the systems that hold source data, such as document stores, customer records and registries. Authentication is wired to the organization's identity provider, and every task completion writes the actor, timestamp and form data to the engine's history. Confirm with the engine vendor and your architects which history and REST interfaces your chosen engine exposes. Output: an integration map listing each system, data field, direction, authentication method and failure behavior.
Test with real case scenarios and audit review
Testers run the model against anonymized or synthetic cases drawn from past files, including the awkward ones: reopened cases, missed deadlines, duplicate submissions and tasks reassigned mid-stage. Compliance or internal audit staff check that each case produces a complete history showing who decided what, when, under which decision table version. Defects are logged and retested until the agreed exit criteria are met. Output: a test evidence pack with scenario results, defect closure records and the audit review sign-off.
Pilot with one team
One team works live cases through the new case type while the previous process remains available as a fallback. The pilot measures whether caseworkers can complete tasks without workarounds, whether deadlines are visible, and whether the audit history answers the questions reviewers ask. Problems found in the pilot go through the change process before wider use. Output: a pilot review record listing accepted behavior, changes made and the go or no-go decision for production.
Cut over and run in production with monitoring
The team deploys the approved model to the production environment, migrates or closes in-flight cases according to the cutover plan, and turns on monitoring for stuck cases, failed integration calls, overdue milestones and async job health. Operations staff receive a runbook covering restart procedures, escalation paths, backup and restore, and how to roll back a model version. Confirm the monitoring and clustering capabilities of your chosen engine and its database before go-live. Output: a cutover record and an operational runbook accepted by the service owner.
Govern changes through a documented process
Every later change to the case model, decision tables, forms or integrations follows the same path: a change request, a review by the process owner, testing against the saved scenarios, approval, and a recorded deployment. Versions of the case model stay available so that cases started under an earlier version can finish under it. The team reviews audit history and monitoring data on a set schedule agreed with the business. Output: a change log linked to test evidence and an approval record for each release.
Evidence that auditors and regulators ask for in case handling
This table maps each evidence item an assessor or regulator typically asks for in case handling to the component that produces it: the engine, the database, the identity service or the log store. Read each row as a question to answer during design, since the source system must generate the record before anyone can inspect it. DeployOpen prepares this evidence for the client, but independent auditors and certification bodies assess it.
| Evidence item | Producing component | What to confirm before go-live |
|---|---|---|
| Case model versions and deployment records | Engine (CMMN definitions deployed to the engine's repository tables) | Which deployment ID and model version was active for each case, and how promotions between environments are approved and logged |
| Task assignment and completion history | Engine history tables in the database | Whether history level captures assignee changes, claims, delegations and completion times, and how long history rows are retained |
| Decision and approval records | Engine (human task outcomes and variables) plus any DMN decision tables it calls | Whether the decision table version and inputs are stored with each case, so a past decision can be reproduced |
| Retention and deletion logs | Database and log store, with a documented retention job | Whether deletion runs are logged, which records are purged, and how legal holds stop purges for open cases |
| Access control records from the identity service | Identity provider (for example LDAP or OIDC) and engine user and group mappings | Which identity events, group changes and role grants are logged, and whether those logs are kept outside the engine |
| Backup and restore test results | Database backup tooling and a documented restore runbook | Whether restores of case data are tested on a schedule, with the test date, scope and result recorded |
| Automatically generated event logs | Log store receiving engine and API logs | Whether logs are retained long enough for the regulatory period that applies, and whether AI-assisted steps are logged where the EU AI Act applies |
What buyers ask before hiring help for CMMN case management
What drives the implementation effort and cost for a CMMN case project?
The main drivers are the number of case types, how many stages, milestones and human tasks each case contains, how many source systems the case must read from or write to, and how the task interface is built. Identity integration, migration from an older engine, and the amount of reporting and audit evidence required also move the effort. DeployOpen does not publish a price list, so ask for a written scope that lists each case type, each integration, each task screen and each migration item as a separate line. Ask the partner to state which items are fixed and which depend on client input.
What is one-time work and what recurs after go-live?
One-time work usually covers case modeling, integration build, task UI, test automation, environment setup and initial documentation. Recurring work covers patch and minor upgrades, security updates to the runtime and database, backup verification, monitoring, and changes to case models as policies change. Operaton publishes monthly patch releases and supports each major or minor version for 6 months until the next one ships, so budget for a regular upgrade cycle. Ask whether the partner offers a support retainer, what response expectations it covers, and how upgrades are tested before they reach production.
What does the client team need to provide for the project?
The work needs named case owners who can decide how a claim, complaint or permit moves through its stages, subject experts who can explain exceptions, and a test data set that reflects real volumes without exposing personal data beyond what policy allows. It also needs an approver for change requests and access to the people who run the source systems. Ask the partner to list these roles in the scope with an estimated time commitment per role, and to name who signs off each case model before it is deployed.
Can our in-house team build and run a CMMN solution without a partner?
Yes, if the team has Java or Spring experience, can operate a relational database cluster, and has someone who understands case modeling. Flowable and Operaton are open source, and both include the CMMN engine. The harder parts are usually the task interface, the integration layer, the upgrade discipline and the evidence for audit. Ask yourself whether those skills will be available for the life of the system, not only during the first build. A partner can cover some of those gaps through a fixed-scope build, a handover, or an ongoing retainer.
How do license terms affect running CMMN in production?
License terms decide whether an engine can run in production at all, and whether it can be embedded in a product you ship. Flowable open source is licensed under Apache 2.0, and Operaton is Apache-2.0 with no open-core model. Camunda 8 source code is under the Camunda License 1.0, which permits use only in non-production environments without a commercial license. Confirm the exact license of every component you plan to deploy, including the database driver, the UI and any add-ons, with legal counsel before the scope is signed.
How long does a CMMN pilot take to scope?
The scope itself depends on how many case types are in the pilot and how many systems each one touches. A useful pilot scope names one or two case types, the decisions and tasks inside them, the integrations they require, the audit events that must be captured, and the success criteria agreed with the case owners. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so ask for a written scoping document with a schedule and dependencies listed. Do not accept a pilot duration that is not tied to a named list of deliverables.
What evidence should the partner provide for case history and audit?
A credible partner should show how each case records its creation, each stage transition, each human task assignment and completion, and each decision with the actor and time. Ask how the engine's history tables are configured, how long they are kept, how they are backed up, and how they are protected from edits. Ask also how case data is separated from personal data where retention rules apply. Where the case supports a high-risk AI system, the EU AI Act requires automatic event logging under Article 12(1) and retention of logs for at least six months under Article 19(1), so confirm those obligations with your compliance lead.
How is identity handled for case owners and approvers?
Case owners, approvers and auditors need roles that match their authority, and the engine must enforce those roles on every task. Flowable documents that identity management can be replaced through its identity service interface, with an LDAP implementation provided as a reference. Ask the partner which directory you use, whether group membership is synced or queried live, and how separation of duties is enforced for approvals. Confirm these details during scoping because they change the integration work.
Questions to ask a partner before committing to CMMN
Start with how the partner tests case models before any case type reaches production. Ask them to show a test suite that drives a case through its stages, sentries, milestones and human tasks, including the paths where a deadline passes or a document arrives late. Ask which CMMN 1.1 constructs their models use and how they verify that a case stage behaves the same way when a claimant or applicant takes an unexpected route. The answer should name the test tooling, who writes the tests (the partner, your team or both), and where the test evidence is stored so that your change approvers can review it. Ask whether they test against the database engine you will run in production, not only an embedded in-memory database.
Next, ask how running cases are handled when a case model changes. A new version of a permit or complaint model should not silently alter cases that are already open. Ask the partner to explain how they decide between leaving open cases on the old model version, migrating them, or closing and reopening them, and who signs off on each choice. Ask for a written migration procedure with a rollback step, and ask how they will report which cases were moved and to which version. Ask how audit history is exported and retained: which fields leave the engine, in what format, how long they are kept, and whether the export preserves the original version of the case model that applied when each decision was recorded.
Ask how the task UI enforces access control. CMMN case tasks often expose claim files, investigation notes or citizen data, so ask whether the partner builds role checks on the task list and case view, and whether those checks are backed by your identity provider rather than local accounts. Ask how the engine is clustered, how asynchronous jobs such as timers and deadline escalations are coordinated across nodes, and which database versions they support in production. Finally, ask how they will handle existing cases if you run Camunda 7 or Operaton today. Require a written scope that lists the first set of case types by name, with a deliverable for each, so that you can check progress and cost against named work.
How DeployOpen scopes and supports a CMMN case implementation
The sequence below shows how a CMMN case implementation moves from a written scope to a running, documented and supported system inside the client's own infrastructure. Each step closes with a named output so both sides know when it is complete.
Confirm the case types and scope in writing
DeployOpen works with the client's case owners, process analysts and security team to list the case types in scope, such as claims, complaints, investigations or permits, and the systems each one touches. The output is a written scope and deliverables document that both parties sign before work starts. The engagement is fixed-scope, so anything outside that document is agreed separately as a change. Done means every in-scope case type has a named owner and a listed set of deliverables.
Select the engine and hosting model
The team compares the candidate CMMN-capable engines against the client's license constraints, database standard, Java and Spring skills, and whether production use is permitted under the chosen license. DeployOpen documents the choice in an architecture decision record that covers where the engine, database and file storage run. Done means the client's architecture and security teams have accepted the decision record and the license position has been confirmed in writing.
Model cases, tasks and decision points
DeployOpen models case plan items, stages, human tasks, milestones and sentries with the client's case owners, and separates the decision logic that belongs in DMN tables. Each case type is reviewed with the people who make the decisions, so that the human task list reflects real authority and not a process map drawn from documents. Done means each case model has been walked through with its owners and the open questions are logged with an owner and a date.
Build integrations and the task interface
The team connects the case engine to identity, document storage, source systems and notification channels, and builds or configures the task UI that case workers use. Access rules for each role are implemented and tested, including who can view case data and who can close a case. Done means each integration has passed a test run with production-like data in a non-production environment and the role matrix has been signed off by the client.
Harden, back up and document the platform
DeployOpen applies the client's hardening baseline to the engine, database, application servers and file storage, configures backup and restore for case data and audit history, and writes the operating documentation. Restore is tested on a copy, not assumed. Done means a restore test has completed, the runbooks are handed over, and the client's operations team has confirmed they can run the platform without DeployOpen present.
Prepare evidence for compliance assessments
DeployOpen collects the configuration records, access reviews, change logs and test results that an internal or external assessor will ask for, and maps them to the client's control framework. DeployOpen prepares this evidence but does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. Done means the evidence pack has been reviewed by the client's compliance lead and gaps are recorded with owners.
Launch, hand over and support over time
The case types go live in agreed phases, with monitoring and a support path in place from the first day. After handover, the client can keep DeployOpen on a retainer for upgrades, patching, security testing and support, or run the platform with its own staff. Done means the go-live checklist is signed, the handover is complete and the support model, whether retainer or internal, is recorded in the written agreement.
