BPM for the public sector

Permits, benefits and inspections need deadlines, records retention and registry integration that a process engine must meet in the agency's own infrastructure. This page covers the requirements, the platform choice and the rollout, including why production licensing decides which engine you can use.

On this page

Why BPM for the public sector needs open source checked against production licensing

Many agencies still run permit, benefit and inspection cases on spreadsheets, shared mailboxes and paper files, and the question is how to move that work onto a self-hosted BPM and case engine without creating a licensing problem later. The short answer is that Flowable (Apache-2.0) covers BPMN, CMMN and DMN inside the agency's own infrastructure, while the Camunda 8 source code permits only non-production use without a commercial license. Public bodies therefore need to test the license against the environment they will actually run, not the environment they pilot in.

Public bodies carry obligations that differ from most other sectors. Citizen-facing deadlines, such as statutory decision periods for a benefit or permit, have to be timed, escalated and evidenced. Records retention schedules decide how long case files, decisions and task histories must be kept and when they may be disposed of. Integration with national and municipal registries determines whether a case can be verified against the source of truth, and data residency rules often require that citizen data and process variables stay in national or regional facilities. Each of these affects engine choice, database placement and where audit history is stored.

Before selecting an engine, the reader should confirm three things with the legal and procurement team: which environments count as production, whether any pilot or test system will hold live personal data, and who will own the license position once the engine is upgraded. Ask any implementation partner to show, in writing, which license terms apply to each environment and which version of the engine the quote assumes. The Flowable open source page is the natural starting point for the engine's scope, but the license decision belongs in the procurement file.

Which public sector requirements shape the BPM build

This table maps the public sector requirements most likely to apply to a BPM build to what each one means for the process engine, forms, audit history and hosting. Read each row against your jurisdiction and data types, since several requirements apply only when specific data or bodies are involved. The main takeaway is that hosting location, identity, audit evidence and accessibility are usually decided at design time, not added after go-live.

RequirementWhat it means for the BPM buildEvidence to prepare
CJIS Security Policy v6.1 (where criminal justice information appears)Encrypt CJI in transit and at rest outside physically secure locations with FIPS 140-3 validated modules or AES-256 keys, and scan for vulnerabilities at least monthly. Keep case variables that hold CJI out of general-purpose logs.Encryption configuration, FIPS module attestation from the vendor, scan schedule and results
NIST SP 800-53 baselines and FISMA oversight (federal bodies)Select a low, moderate or high baseline for the process platform and map controls to the engine, database, forms and gateway. Inspectors General assess agency systems independently, so control mapping must be traceable.Baseline selection, control mapping in OSCAL or a similar format, system security plan entries
FedRAMP scope (cloud-hosted case systems)If a cloud provider hosts the case system as a shared service for federal information, FedRAMP applies to that provider. A system used only for one agency's operations on cloud infrastructure may fall outside scope, so confirm the classification before choosing hosting.Written scope determination, provider authorization status where in scope
32 CFR 2002.14(h)(2) and NIST SP 800-171 (CUI)Federal agencies use NIST SP 800-171 to set safeguards for controlled unclassified information on non-federal systems, unless the CUI category prescribes otherwise. Forms, attachments and task queues holding CUI need the same protections as the engine that processes them.CUI category markings in the data model, safeguard mapping, access logs
ADA Title II web and mobile rule (WCAG 2.1 A and AA)State and local government web content and mobile apps, including those delivered by contractors, must meet WCAG 2.1 Level A and AA from 26 April 2027 for entities serving 50,000 or more people, and from 26 April 2028 for smaller entities and special districts. Human task forms and citizen status pages fall within this scope.Accessibility test results against WCAG 2.1 A and AA, remediation log, conformance statement owned by the entity
NIS2 (public administration)NIS2 covers central government entities regardless of size and lists public administration as a sector of high criticality. Member States may extend it to local administration. It does not apply to entities working in national security, public security, defense or law enforcement, so confirm the exclusion for each process.Scope determination for each entity, incident handling and supplier security records for the platform
EU AI Act logging (only where AI influences decisions)If an AI component supports a decision in a high-risk use, Article 12(1) requires automatic event logging over the system's lifetime, and Article 19(1) requires providers to keep those logs for at least six months unless other law sets a longer period. Pure rules-based routing does not trigger this on its own.Log schema for AI-assisted steps, retention settings, classification memo for the use case
Records retention and audit history (general)Process instances, task decisions, forms and deadline timers must be retained for the period set by your records schedule. Plan archiving of completed instances and an audit trail that can show who acted, when and under which process version.Retention schedule mapped to process models, archive test restores, version history of process definitions

How hosting and data rules change where the engine runs

US federal agencies and the bodies that handle criminal justice information (CJI) face the strictest hosting constraints in this set. FedRAMP's scope covers cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency, and systems used only for a single agency's operations on cloud infrastructure that are not offered as a shared service are out of scope. That distinction determines whether a self-hosted Flowable deployment in an agency's own cloud account needs a FedRAMP authorization path or sits outside it, and it is a question for the authorizing official and counsel, not for the engineering team alone. For CJI, the FBI CJIS Security Policy version 6.1 took effect on 26 June 2026 and requires FIPS 140-3 certified modules or FIPS 197 AES with at least 256-bit keys for CJI in transit and at rest outside physically secure locations.

  • Cloud scope decision: Document whether the engine, database and task UI are a single agency operation or a shared service before choosing a hosting location.
  • Key management: Plan HSM or KMS use with FIPS 140-3 validated modules and 256-bit AES keys for database volumes, backups and message transport.
  • Vulnerability scanning: Schedule scanning of the engine, its database and the task UI at least monthly, as the CJIS requirements call for.
  • Vendor choice: Confirm each managed database or cloud service used for CJI meets the policy requirements before it is added to the architecture.
  • Control mapping: Map the deployment to NIST SP 800-53 Rev. 5 control families and the applicable baseline.

Confirm the cloud scope determination in writing with the authorizing official and counsel before the architecture review begins.

Which open-source engines fit public sector case work and why

Permit, benefit and inspection work needs an engine that runs BPMN and CMMN, keeps audit history and fits the license terms of production use. The cards below cover the engines and supporting tools that teams most often evaluate, with the license and operational checks to run before committing.

Flowable as the core engine

Flowable is licensed under Apache-2.0 and provides BPMN process execution, CMMN case management and DMN decision rules with Java and REST APIs. Flowable 8.0.0 was published on February 27, 2026 and requires Spring Boot 4 and Spring Framework 7, so Spring Boot 3 applications need a migration plan. Confirm that your database platform is supported, since the configuration docs list PostgreSQL and Oracle among others.

Camunda 8 and production licensing

Camunda 8 source code is distributed under the Camunda License 1.0, which permits use only in non-production environments without a commercial license. Public sector teams that need an open license for production should treat Camunda 8 as a development or test option unless a commercial agreement is in place. Ask any partner to show the license terms for each component they propose before the architecture is fixed.

Node-RED for integration glue

Node-RED, licensed under Apache-2.0, can connect legacy case systems, file drops and registry endpoints through flows that are easy to review. It works best for thin adapters, such as moving a notification or reading a status, while business rules and deadlines stay in the BPMN model. Check who owns each flow, how credentials are stored and how flow changes go through testing before production.

Airflow or Dagster for batch reporting

Apache Airflow and Dagster are suited to scheduled work such as monthly statistical extracts, backlog reports and retention clean-up jobs. Both are open source, Airflow under Apache-2.0 and Dagster under Apache-2.0, but they are not designed to run citizen-facing case steps. Keep them out of the path of live deadlines, and confirm who approves the reporting schedules and the data that leaves the case system.

Optional Flowable commercial products

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. They are optional. Open source users get a community forum, while professional services and partners are offered separately, so budget for support and upgrades as a separate line item.

Operating the engine in production

Clustered deployments depend on the async executor, which coordinates nodes through lock owners and lock expiration times stored in the database, so expired locks are recovered by other nodes. Test failover and job recovery before go-live. Identity can be replaced through an identity service interface, with an LDAP reference implementation, so confirm how caseworker roles from your directory map into task assignment.

Integration points that registries and citizen services require

Permit, benefit and inspection processes rarely run alone. They pull eligibility data from national registries, authenticate staff against directories, and must keep running through node failures and upgrades. The cards below cover the integration and operational components that determine whether a BPMN or CMMN deployment holds up in production.

X-Road for secure data exchange

X-Road is open-source software for unified, secure data exchange between organizations, published under the MIT license. Its Central Server, Security Server and Configuration Proxy form the exchange layer, so a case process can query a registry through a governed channel rather than a point-to-point connection. Check the Security Server's PostgreSQL requirement, its firewall ports (5500, 5577, 4000, 8080 or 8443), PKCS#11 hardware security module support for signing keys, and whether your target Ubuntu or RHEL versions appear in the installation guide.

X-Road version decision

X-Road 7.8.3 is the current release, and 7.8.0 is the last new-feature release of the 7 line. X-Road 8 is in beta testing, with a production release scheduled for December 2026. NIIS has not decided how long X-Road 7 will receive security patches beyond 2026, so ask the national registry operator which line it will connect to before you choose a version. Build the upgrade path into the project plan from the start.

Async executor and multi-node locking

The Flowable async executor runs timers and asynchronous jobs from a thread pool. Nodes coordinate through lock owners and lock expiration times stored in the database, so when a node fails, expired locks are released and another node picks up its jobs. For deadline-driven permits and benefit reviews, confirm lock expiry settings, test failover with running timers, and verify that the database engine you choose is on the supported list.

Staff identity through IdmIdentityService

Flowable lets you replace its identity management by overriding IdmIdentityServiceImpl or implementing the IdmIdentityService interface, and it ships an LDAP identity service as a reference. Caseworker roles, supervisor groups and candidate lists for human tasks should come from the agency directory, not from a local user table. Confirm which group attributes your directory exposes, how role changes take effect for open tasks, and who approves changes to the mapping.

Monitoring running processes with actuator

With the Flowable Spring Boot starters, an actuator endpoint at /actuator/flowable exposes information about running processes. Operations teams can use it to watch for stalled instances, growing backlogs of overdue tasks and jobs waiting on timers. Decide which metrics feed your monitoring stack, restrict who can reach the endpoint, and confirm that its output contains no citizen data before it reaches shared dashboards.

Spring Boot and Java version constraints

Flowable 8.0.0 moved to Spring Framework 7 and Spring Boot 4 and dropped support for Spring Boot 3, so an agency's existing Spring Boot 3 services cannot share that stack without a migration. Flowable 7.0.0 requires Java 17 or later and Jakarta EE. Before selecting a Flowable line, inventory the Java and Spring versions already approved for agency hosting and test the engine on that exact stack.

How a public agency moves permits or benefits onto the engine

The sequence starts with licensing and process inventory, then proves the design on one service and one registry before any citizen-facing case moves. Each phase closes with a written output that the agency's owners can approve.

  1. Confirm scope and licensing position

    The agency and DeployOpen agree which services, departments and citizen channels are in scope, and who owns the decisions for each. The team reviews the license of every engine and component against the production use the agency plans, including whether the chosen BPMN engine permits production use without a commercial license. Flowable's engines are Apache-2.0, while Camunda 8 source code under the Camunda License 1.0 permits only non-production use without a commercial license, so this check must be documented before any build starts. The output is a signed scope statement and a license register that the procurement and legal teams have reviewed.

  2. Inventory processes, deadlines and retention rules

    Business analysts and service owners map each permit or benefit path as BPMN, and mark where the work is unstructured enough to need CMMN case management. For each process they record statutory deadlines, notification duties, decision points, required documents and the records retention period that applies to each record type. Staff confirm the rules against the current legislation and internal policy, not against memory of past practice. The output is a process inventory with a rule sheet per service, which becomes the acceptance baseline for testing.

  3. Pilot one service with accessibility testing

    The team builds one service end to end on a non-production environment, including the human task screens, citizen forms and status pages that the public uses. Accessibility testing runs against WCAG 2.1 Level A and AA, the success criteria that the ADA Title II rule adopts for state and local government web content and mobile apps, with the compliance date depending on the size of the entity. Testers include staff who use assistive technology, and defects are logged against the criteria they fail. The output is a pilot service, a test report with open defects and an accessibility conformance statement prepared for the agency's own review.

  4. Integrate one registry through X-Road

    The team connects the pilot to one national or regional registry through an X-Road Security Server, which the agency must provision and operate within its own infrastructure and PostgreSQL database. The integration agrees message schemas, service owners, access rights and the handling of errors and timeouts, so a failed lookup routes the case to a human task rather than stalling silently. Hardware security modules can hold the signing keys through PKCS#11 where the agency's policy requires it. The output is a tested registry connection, documented access rights and a runbook for registry outages, approved by the registry owner.

  5. Run the pilot in parallel with current operations

    For a defined set of new applications, the engine and the existing process run side by side, and staff compare outcomes, deadlines, notifications and retained records case by case. Discrepancies are classified as process design errors, rule interpretation issues, integration faults or data quality problems, and each class has an owner. The team checks that the audit history records who did what and which rule version applied, which supports later review of automated decisions. The output is a parallel run report with each discrepancy resolved or accepted by the service owner.

  6. Cut over with running instance handling

    Before cutover, the team decides for every open case whether it finishes on the old process, migrates to the new model, or is closed and reopened, and records that decision per case type. Process versions are tagged so that cases started under an earlier rule set keep their original logic. Operations staff confirm backup, clustering and monitoring for the production engine, and the rollback path is rehearsed. The output is a cutover record listing migrated, completed and transferred instances, plus a signed go-live approval from the service owner and the agency's security function.

Evidence auditors and oversight bodies ask for from the case system

This table maps the evidence reviewers typically request for a permit, benefits or inspection case system to the component that produces it. Read each row as a question an assessor may ask, the place the answer lives, and the gap to close before the review. DeployOpen prepares this evidence, while auditors, certification bodies and oversight staff reach the conclusions.

Evidence areaWhat it showsWhere it comes from
Process version historyWhich BPMN and CMMN model version governed each case, and when it changedEngine deployment tables and model repository history, linked to CI pipeline approvals
Deployment and change recordsWho promoted each model or code release to production and after which testsCI/CD logs, change tickets and signed release artifacts from the build pipeline
Task and decision audit trailWho completed each human task, what they decided and the deadline status at that timeEngine history tables in the relational database, exported on a schedule to write-once storage
DMN rule version per decisionWhich decision table version determined eligibility or a benefit amount for a given caseDecision history records keyed to the case instance and deployed rule version
Access control and identity logsWhich caseworkers and administrators had which roles, and when access was granted or removedIdentity provider logs, directory group history and application role assignments
Encryption configuration for CJI or CUIAlgorithms and key lengths protecting data in transit and at rest, including key custodyTLS configuration, database and storage encryption settings, and HSM or key management records
Vulnerability scan resultsEvidence of scanning at the frequency the applicable policy requires, with remediation trackingScanner reports for hosts, containers and the application, stored with ticket references
Retention schedules for case filesHow long each record class is kept, and proof that deletion ran under the approved scheduleRetention rules configured in the case store, deletion logs and records officer sign-off
AI decision logs where Articles 12 and 19 applyAutomatic event logs for any AI-assisted triage or scoring, kept for the period the regulation setsGateway and model call logs with prompt, output and model version, stored in the organization's own storage

What public agencies ask before hiring an implementation partner

What drives the cost of a public sector BPM implementation?

The main cost drivers are the number of processes to model, how many registries and legacy systems must be integrated, how much citizen-facing interface work is needed, and where the platform is hosted. Modeling volume scales with the number of permit, benefit and inspection types and their variants. Each registry connection requires interface design, data mapping, test environments and access approvals from the registry owner. Accessibility work adds effort because state and local government web content and mobile apps must meet WCAG 2.1 Level A and AA under the ADA Title II rule, with compliance dates of 26 April 2027 for entities serving 50,000 or more people and 26 April 2028 for smaller entities and special districts (28 CFR 35.200). Ask any partner for a fixed-scope quote that separates modeling, integration, task interfaces, hosting and migration, and states which items are one-time and which recur through support.

How long does a public sector case management rollout take?

The duration depends on how many processes go live in the first phase, how many registries must be connected, and how quickly the agency can approve designs and test results. A single benefit or permit process with one registry connection will take far less time than a multi-program rollout with several registries and a records retention scheme. Ask the partner for a timeline built from the agreed scope, with dependencies on registry access, security approvals and accessibility testing shown as separate milestones. Treat any duration given before scope is written as an estimate to challenge, not a commitment.

What must our staff provide before an implementation starts?

The agency must supply named process owners who can make decisions on case rules, deadlines and exception handling, plus legal and records staff who can confirm retention periods for each case type. Registry owners must provide test access, interface documentation and approval for production connections. Security staff should confirm hosting rules, identity sources and any requirements that apply to criminal justice or controlled data. Without these inputs, modeling stalls and the scope drifts. Ask the partner to list these roles and dependencies in the written scope so the agency can assign people before work begins.

Can our agency run a BPMN platform itself after go-live?

Yes, if the agency builds internal skills for operating the engine, maintaining process models, and handling upgrades. Flowable is licensed under Apache-2.0 and offers Java and REST APIs, supports PostgreSQL, Oracle, MySQL, DB2 and Microsoft SQL Server, and can run as a Spring Boot application with an actuator endpoint at /actuator/flowable. The open source engines do not include a full low-code modeling or task UI, so the agency must either build those or buy them separately. Ask the partner which operational tasks transfer to the agency, which remain under a support retainer, and what documentation and training are included.

Does production use of Flowable require a commercial license?

Flowable open source is licensed under Apache-2.0, so the engines can be used in production without a license fee for the open source code. Commercial Flowable products such as Flowable Work, Engage, Orchestrate and Design are separate offerings built on the same engines and add low-code modeling, visual debugging, security controls and monitoring. Agencies that want those features, or vendor professional services, should price them separately. Confirm the license terms of every component in the stack, including any commercial extensions, with the vendor and your procurement and legal teams before signing.

How do we handle Camunda 7 or legacy engines in a migration?

Camunda 8 source code is under the Camunda License 1.0, which permits use only in non-production environments without a commercial license, so agencies cannot assume a Camunda 8 deployment is free for production. Legacy engines such as Activiti or Camunda 7 processes need an inventory of running instances, a mapping of their BPMN constructs to the target engine, and a plan for in-flight cases. Flowable 7.0.0 moved to Java 17, Spring Boot 3 and Jakarta EE, and Flowable 8.0.0 moved to Spring Framework 7 and Spring Boot 4 without backward compatibility for Spring Boot 3, so the target version affects the whole stack. Ask the partner to show a migration inventory and a test plan before committing to a timeline.

What compliance evidence should a public sector BPM project produce?

Agencies should expect evidence that matches the frameworks that govern their data. That usually includes an access control design, audit history for each case decision, records retention rules mapped to case types, and documented change approvals for process models. Where criminal justice information is involved, the FBI CJIS Security Policy version 6.1, effective 26 June 2026, requires FIPS 140-3 certified modules or AES with 256-bit keys for data outside physically secure locations and at least monthly vulnerability scanning. Federal programs may also refer to NIST SP 800-53 Release 5.2.0 baselines. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors and certification bodies issue the audit reports or certifications. Ask the partner which evidence will be delivered and which assessor will review it.

Does hosting in our own data center or cloud account change the project?

Yes. Hosting decisions affect the infrastructure work, the security approvals and the ongoing operating cost. Self-hosting inside the agency's own data center or cloud account keeps case data under its control, but the agency or its partner must size the servers, database, backups, monitoring and patching. Federal cloud rules may apply: FedRAMP's scope covers cloud products that process federal information on behalf of an agency, so a cloud deployment serving several agencies may need authorization. Ask the partner to name the hosting model, the database engine, the backup and restore tests, and the teams responsible for each layer.

Questions to ask a partner before a public sector BPM contract

Start with deadline and timer logic, because a missed statutory clock is the failure a citizen will notice first. Ask the partner how they test timers that run for weeks or months, including what happens when a clock crosses a public holiday, a time zone change or a daylight saving shift, and whether the test suite replays those cases against the Flowable async executor settings in the target environment. Ask how they prove that a timer which fires on a node that was restarted still fires exactly once, since the async executor recovers expired locks across nodes. Request the test cases themselves, not a summary of them, and confirm who owns the calendar data that defines a working day for each permit or benefit type.

Next, ask how retention rules and records stay out of process variables. A partner who stores applicant identifiers, case notes or document content as engine variables will make retention and deletion hard to enforce, because history tables keep copies. Ask where case files live, how a process holds only a reference such as a case identifier, and how the records system applies a retention schedule that is independent of the workflow engine. Ask how they map CJIS Security Policy v6.1, NIST SP 800-53 baselines or NIS2 obligations to specific controls, and whether that mapping is delivered as an OSCAL or spreadsheet artifact your assessor can trace. Ask what the partner will not claim: DeployOpen prepares controls and evidence, but auditors and certification bodies issue the findings.

Finally, ask about running instances, production licensing and accessibility. Ask how the partner migrates instances that are already in flight when a process definition changes, and whether they have a written rollback plan. Ask them to confirm the engine license in writing: Flowable is Apache-2.0, while Camunda 8 source code under the Camunda License 1.0 permits only non-production use without a commercial license, so the answer must cover production clusters, test environments and any bundled components. For accessibility, the ADA Title II rule applies WCAG 2.1 Level A and AA to task portals and forms, with compliance dates in 2027 or 2028 depending on population size. Ask what accessibility testing they run, which tools and assistive technologies they use, and what report and remediation log you receive.

How DeployOpen scopes and supports public sector case management

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source process platforms inside the agency's own cloud accounts, data centers or air-gapped networks. For public sector case management, that means the work starts from the permit, benefit or inspection rules and the controls that apply to the data, and ends with a platform the agency can run and evidence it can show.

How we scope

  • Written scope lists the case types, deadline rules and registry integrations in the first phase
  • Records retention requirements are agreed with the agency's records officer before modeling begins
  • Fixed-scope engagements define deliverables, timelines and acceptance criteria in writing before work starts

How we build

  • Engine selection is confirmed against the license terms for production use, including Camunda 8 non-production limits
  • Citizen-facing deadlines are modeled with timers and tested against the agency's published service rules
  • Access to case files is limited by role, and personal data stays in the agency's own database

How we hand over

  • Process models, decision tables and integration designs are documented in a form the agency's teams can maintain
  • Test evidence covers deadline paths, escalations and audit history for each case type before go-live
  • Operating runbooks cover backups, engine upgrades and clustering so staff can run the platform after handover

How we support

  • Ongoing support, upgrades and continuous testing are available as retainers after handover
  • Security testing of the case portal and its APIs can be scoped separately from the process engine work
  • Compliance readiness packs map the platform's controls and logs to the requirements the agency must meet

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.