Why Flowable fits public sector case handling
A permit, benefit or licensing case often touches several departments, waits on external evidence and must be explained later to an applicant, an appeal body or an inspector. Flowable's CMMN, DMN and BPMN engines can run this work inside agency-controlled infrastructure, and the engines are released under Apache 2.0, so the agency can deploy them without a per-seat license for the engine itself. The fit is strongest where the work is a mix of structured steps and unpredictable case activity: CMMN models the case as stages, milestones and sentries that a caseworker can progress, while BPMN handles the fixed sequences such as payment or notification steps, and DMN keeps eligibility and fee rules out of code.
For the agency, three things change. Case status becomes a question the system answers from recorded state, not from the memory of whoever last touched the file. Decision logic lives in DMN decision tables that policy staff can review, version and publish, and the rule a decision used on a given date can be traced through the decision history. The engines also record process and case history, which gives the audit trail that oversight bodies ask for. Confirm with your records and legal teams which history fields must be kept and for how long, because the engine records what happened but does not decide the retention period for you.
The engines are libraries and APIs, not a finished citizen portal or caseworker desktop. Your agency, or the partner it hires, builds the front ends, the identity integration, the document handling and the accessibility of every screen the public uses, and those choices sit in the agency's own scope. Plan that work alongside the engine build from the start. Ask the implementation team which parts of the authorization model they will implement in the application, because the engines do not decide who may approve a permit or view a file on their own.
Which public sector requirements shape the Flowable build
This table maps the public sector requirements most likely to affect a Flowable deployment to the decisions they force on hosting, key management, front-end testing and data flows. Read each row as a question to answer in the design phase, then confirm the applicable baseline and jurisdiction with your legal, compliance and security teams before fixing the architecture.
| Requirement | What it means for the Flowable build | Evidence an assessor will expect |
|---|---|---|
| NIST SP 800-53 baselines and FISMA oversight | Choose a low, moderate or high baseline early, since it sets how many controls the engine hosts, logging and access design must satisfy. Map Flowable components (engines, REST API, database, identity) to controls and keep the boundary explicit. | A system security plan mapping each Flowable component to controls, plus evidence that Inspectors General or agency reviewers can trace to it |
| CJIS Security Policy encryption and scanning | If criminal justice information appears in process variables, documents or history, encrypt it in transit and at rest with FIPS 140-3 validated modules or AES with 256-bit keys outside physically secure locations. Keep CJI out of logs and DMN test data, and schedule at least monthly vulnerability scanning of the engine hosts. | Encryption configuration for databases, backups and message paths, key custody records, and monthly scan reports |
| 32 CFR 2002.14 and CUI on non-federal systems | Agencies using NIST SP 800-171 to protect controlled unclassified information on non-federal systems means a case system holding CUI inherits those safeguards. Confirm which CUI categories apply, since their authorities may prescribe other safeguards. | Documented CUI categories in case data, access restrictions on process variables, and the safeguard mapping for the hosting environment |
| CMMC cloud scope for defense-related CUI | For defense contractors, storing or processing CUI in a cloud service requires FedRAMP Authorized Moderate or higher, or equivalent. Self-hosting Flowable in your own accounts changes which service provider is assessed, so confirm scope with your assessor before choosing a cloud region. | Written scope boundary identifying the hosting provider, and provider authorization status supplied by the provider |
| ADA Title II WCAG 2.1 AA deadlines | Custom Flowable task front ends, citizen forms and mobile screens must meet WCAG 2.1 Level A and AA. Deadlines are 26 April 2027 for entities serving 50,000 or more people and 26 April 2028 for smaller entities and special districts, and the rule covers contracted or licensed content. Include assistive technology testing in each release of the REST-based front end. | Accessibility test results against WCAG 2.1 AA, a conformance statement for each release, and contract language assigning accessibility duties |
| NIS2 applicability to public administration | Central government entities fall under NIS2 regardless of size, and Member States may extend it to local public administration. It excludes national security, public security, defense and law enforcement entities. Confirm your status with national authorities, then plan logging, incident reporting and supplier controls for the Flowable platform if it applies. | Confirmed scope determination, incident response procedure covering the engines and their database, and supplier security terms |
| GDPR Chapter V transfer rules | Hosting Flowable in an EU data center with EU-only administration avoids most transfer issues. Remote access from a third country, even for display-only support, counts as a transfer, as does cloud storage outside the EEA. Review processor contracts for third-country law exposure, and plan key management so data stays readable only inside approved locations. | Records of processing, transfer impact assessments, standard contractual clauses where applicable, and a list of support locations with access rights |
On-premises, sovereign or cloud hosting for agency workflows
Running Flowable on servers the agency owns or leases keeps the engines, database and logs inside infrastructure the agency controls. The cloud-specific rules in the supplied facts, including FedRAMP scope, do not apply to a system used only for one agency's operations on its own infrastructure, but other controls still do. The agency remains responsible for every control in its security plan, whether the workload is hosted on-premises or elsewhere.
- Scope of cloud rules: FedRAMP covers cloud products that handle federal information for an agency, so an agency-run system on its own hardware is generally outside that scope. Confirm this reading with the agency's authorizing official.
- Control ownership: NIST SP 800-53 baselines still apply, and the agency must document how each selected control is met in its own environment.
- Access from outside: Vendor support sessions that display data on a screen can be remote access, so restrict and log them.
- Sustainment: Patching of the Java runtime, Spring stack, database and operating system stays with the agency or its partner.
- Capacity: Sizing of the database, job executor and backups is an agency responsibility.
Confirm with the agency's security office which baseline and control overlays apply, and who signs the authorization decision.
A national or sovereign cloud is operated inside a jurisdiction and usually under local law and local administrators. This reduces the number of transfers that the EDPB guidelines would treat as international, but it does not remove every exposure. Whether a provider's staff abroad can see data in the clear, and whether foreign law can compel the provider, depends on contract terms and the provider's own operating model, which the agency must verify.
- Transfer tests: EDPB Guidelines 05/2021 treat remote access from a third country, even display-only support, as a transfer. Map every administrator location.
- Compelled access: The EDPB Recommendations 01/2020 state that where a provider must access data in the clear and foreign public authority powers exceed what is necessary and proportionate, no effective technical supplementary measure can be envisioned. Get counsel to assess this.
- Data Act protections: Article 32 of the EU Data Act requires providers to take measures against third-country governmental access to non-personal data held in the Union.
- Switching rights: The Data Act gives customers the right to move to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transition.
- Deployment design: Flowable runs as a JAR, Spring application or container, so the engines can be moved between approved environments if the Flowable configuration and database are portable.
Ask the provider for written answers on administrator locations, legal process handling and the exit terms before the design is fixed.
A commercial cloud region can host Flowable under the agency's own deployment design, but the provider's accreditation status, data residency options and legal reach become decisive. For U.S. federal workloads, the FedRAMP scope rules and the agency's authorization path apply, and the provider's authorization must cover the services the workflow engine relies on. For EU public bodies, transfer and foreign access rules apply in addition.
- Federal authorization: FedRAMP applies to cloud products handling federal information for an agency. Confirm whether the provider's offering and region are covered at the baseline the agency needs.
- Legal reach: The CLOUD Act provision at 18 U.S.C. 2713 requires U.S. providers to preserve or disclose data in their control wherever it is stored. Storage in an EU region does not remove this exposure.
- Mutual legal assistance: GDPR Article 48 limits recognition of third-country disclosure orders to those based on an international agreement, which counsel should review.
- Lock-in: Managed database, storage and key services may not move cleanly, so keep Flowable, its schema and exports in portable formats.
- Shared responsibility: The agency still owns Flowable configuration, identity integration, backups and access reviews.
Request the provider's authorization letters, data residency commitments and exit assistance terms, then have the agency's legal team review them against its obligations.
Which Flowable modules and settings matter for permits and benefits
A permit or benefit application usually touches six Flowable parts at once: case structure, eligibility rules, statutory timers, identity, audit history and the database underneath. Each one carries a decision that a public agency should make deliberately and document before build starts.
CMMN stages, sentries and milestones
Permit and benefit files rarely follow one fixed path, so a CMMN case model fits better than a single process. Stages hold the work, sentries decide when a stage opens or a task becomes available, and milestones record progress that caseworkers and auditors can read. Check which conditions are required before a decision can be issued, and confirm that every sentry maps to a rule the agency can point to.
DMN tables for eligibility rules
Eligibility criteria such as income thresholds, residency or household size belong in DMN decision tables, not in scattered expressions. Keep each table's hit policy and inputs written down so a policy team can review them without reading code. Plan versioning so that an application received under one rule set is decided and explained under that same version, even after the rule changes.
Human tasks and timers for statutory deadlines
BPMN user tasks assign work to caseworkers, and boundary or intermediate timers enforce response periods set by statute or local regulation. Confirm with legal counsel exactly when a clock starts and stops, including pauses for requests for information. Timer behavior depends on the async executor, so test deadline expiry under node restarts before go-live.
Identity through IdmIdentityService
Flowable lets you replace the identity service by overriding IdmIdentityServiceImpl or implementing the IdmIdentityService interface, and an LDAP reference implementation is provided. Map caseworker groups, supervisors and reviewers from the agency directory so that task assignment mirrors the approval chain. Confirm which roles can change eligibility rules or reassign cases, since the engine leaves those authorization checks to your application.
History and audit configuration
Flowable history records how a case moved, which tasks were completed and by whom, and which decisions were evaluated. Decide the history level and retention period with records officers before production, because the same data serves appeals, audits and public records requests. Test that history survives archiving and that you can reconstruct a decision from it years later.
Database choice from the supported list
Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server. Choose the engine your agency already operates, backed by its existing backup, high availability and access control standards, and confirm that the version meets the minimum requirements in the configuration docs. Note that MySQL versions below 5.6.4 lack millisecond precision, which affects timer accuracy.
How a public agency rolls out a Flowable case service
The sequence moves a Flowable case service from legal scoping to a staged transfer, with each phase producing a record that gates the next. It keeps records retention, accessibility and hosting decisions in view from the start rather than adding them at the end.
Scope the services and map legal obligations
The agency's program owners, records officer, legal counsel and privacy office agree which permit or benefit types are in scope and which laws, regulations and internal policies govern each one. The team maps each obligation to a process, case or decision it affects, including retention periods, appeal rights, notice requirements and any data sharing with other agencies. The step is complete when the signed scope and obligation register exist and the owners have accepted which obligations the Flowable application must support, and which remain with existing systems.
Set the baseline and hosting decision
The team records the current service baseline, including volumes, handoffs, systems of record and the security categorization of the data involved. Using that baseline, the agency's security and procurement leads decide where the platform will run, whether in an agency data center, a government cloud account or another sovereign setting. The step closes with a documented hosting decision and the control baseline it must meet, which the agency's own assessors should confirm before any build starts.
Pilot one permit or benefit type
The team builds a CMMN case model and any BPMN processes and DMN decision tables for a single, bounded permit or benefit type, with named caseworkers testing the flow against real but non-production examples. Business owners review the decision logic and its explanation, and the records team confirms which case documents and history must be kept. The pilot is complete when the owners sign off on the case behavior, the decision tables carry their approved versions, and the open issues are logged with owners.
Test accessibility and security before exposure
Because custom front ends for residents and caseworkers may fall under web accessibility requirements that apply to state and local government, the team tests them against the WCAG 2.1 Level A and AA criteria the agency is expected to meet, using both automated checks and assistive technology review. Security testing covers the Flowable REST and Java APIs, identity integration, cryptographic settings for data in transit and at rest, and vulnerability scanning cadence. The step closes with a dated test report, a remediation list and the agency's acceptance decision.
Run the new service in parallel
For a defined period agreed in the plan, the existing process and the Flowable case service handle the same incoming applications, and the team compares outcomes, decision results, timing and caseworker effort. Discrepancies are traced to either a model defect or a difference in the legacy rules, and each one is resolved and recorded. The parallel run ends when the agency's business owner accepts the reconciliation results and signs the cutover criteria as met.
Transfer in stages with records retention
The agency moves additional permit or benefit types onto the platform in stages, each with its own cutover checklist, rollback path and records transfer plan. Historical and active records are kept according to the retention schedule, and the team confirms that audit history from the Flowable engine can be exported and linked to the official record. The final stage closes when all in-scope services are live, legacy intake is retired or redirected, and the records officer accepts the retention arrangements in writing.
Moving legacy case systems onto Flowable
The migration path Flowable documents for existing case tooling is specific: according to Flowable's September 7, 2022 engineering post, Camunda 7 and Activiti data can be migrated to Flowable in place, including active process instances and history. Flowable also offers the free Flowable LEAP tool, which reports ahead of time what a migration involves. Start with LEAP against a copy of your production database, not a sample, so the report reflects the instances, history volume and definitions your agency actually runs. Ask the Flowable team or your implementation partner to confirm which source versions the tooling covers before you commit to the in-place route, because the published claim is about Camunda 7 and Activiti, not every process or case product a department may have used.
If your agency runs other legacy case tools, treat the migration as a separate assessment. The in-place path does not extend to them by default, so you will need to map their case definitions, stages, task states and decision logic to CMMN and DMN models and decide what can be carried over as data and what must be rebuilt. Document each finding in a scope register that names the owner, the source system and the cutover decision. Where a case is still open on the old system, plan for running instances to finish there or move to Flowable under a defined rule, and record which approach applies to each case type.
Plan running instances and history retention against your records schedule before cutover, not after. Each migrated case carries history that may have its own retention period, and the records officer, not the engineering team, should confirm how long that history must be kept and in what form. Decide which history is migrated, which is exported to an archive you control, and which is disposed of under the schedule, and confirm that the disposal step is tested on a copy. Keep the audit trail of the migration itself, including the LEAP report, the counts of instances moved and any exceptions, so that the records team can show what was moved and why.
What public agencies ask before hiring a Flowable partner
What drives the cost of a Flowable public sector implementation?
The cost follows the written scope: how many case types and decision models are in play, how many systems the engine must integrate with, where it is hosted, how much accessibility testing the public-facing front ends need, and how records retention rules are applied. Each of these adds design, build and test work. Ask any partner to price these components separately so you can see which ones you control. Also ask which costs are one-time, such as design and build, and which recur, such as hosting, upgrades and support. DeployOpen does not publish a price list, so a quote follows from the scope you agree in writing.
How long does a fixed-scope Flowable engagement take?
The written scope sets the timeline. Duration depends on how many case and process models are involved, how many integrations must be built and tested, whether hosting is being prepared at the same time, and how quickly your process owners and policy authorities can review decisions. DeployOpen does not state a standard duration because it varies by scope. Ask for a plan with named phases, deliverables and the dependencies your agency must meet, such as sign-off on policy text and access to test environments.
What must the agency provide before implementation starts?
Most delays come from inputs the agency controls. Plan to provide named process owners who can approve case stages and decision logic, the current policy text or statute references behind each rule, data owners for every system the engine reads from or writes to, and test users who represent caseworkers, applicants and reviewers. You will also need hosting access, identity integration details and a retention schedule that states how long each record type must be kept. Confirm these responsibilities in the statement of work so both sides know who signs off what.
Can our own team build and run Flowable without a partner?
Yes, if your team has the skills. Building on the open-source engines requires Java, Spring and experience modeling BPMN 2.0 processes, CMMN case models and DMN decision tables. Your team also needs to operate the engines, including database administration, deployment of process definitions, monitoring and upgrades. Many agencies start with a partner for the initial design and build, then transfer knowledge to in-house staff. Assess your team against those skills honestly, and ask a partner to document models, delegates and runbooks so they can be maintained internally.
What does ongoing support look like after go-live?
Ongoing support is usually delivered through a retainer, separate from the fixed-scope build. A retainer can cover monitoring, failed job handling, database backups, security patching, Flowable version upgrades, changes to decision rules when policy changes, and periodic accessibility and security testing. Ask what response expectations the retainer sets, which are written as service terms rather than assumed. Confirm how a retainer handles upgrades, since major Flowable releases can change the Java and Spring baseline. Retainer fees recur, so compare them against the cost of an internal support team.
Which compliance evidence can Flowable history and audit data provide?
Flowable history records process and case activity, which can support records retention, audit trails and reviews of how a decision was reached. It does not make a system compliant on its own. Assessments of federal, state or regional requirements are performed by independent auditors or the relevant authority, and DeployOpen prepares systems, controls and evidence for those assessments without issuing audit reports or certifications. Ask your compliance lead which control requirements apply, such as FedRAMP, CJIS or WCAG-related obligations, before the scope is written.
Does the agency need cloud hosting that is already authorized?
It depends on the data, the hosting model and the rules that govern your agency. Public sector requirements, such as the FedRAMP program for cloud services that handle federal information, the FBI CJIS Security Policy for criminal justice information, and NIST SP 800-53 control baselines, can all shape where the engines run. Flowable is open-source software you can run in infrastructure you control, which means the hosting decision is yours to make and document. Confirm with your security office which authorization applies to your data before choosing a cloud provider or on-premises environment.
How DeployOpen scopes and delivers public sector Flowable work
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including cloud accounts, data centers or air-gapped networks. For public sector Flowable work, that means agreeing the scope in writing first, then building and handing over the process, case and decision applications with the evidence an agency's assessors will ask for.
How we scope
- Written scope listing which permit, benefit or case processes, CMMN case models and DMN decision tables are in and out
- Confirmation of the hosting location, identity source and records retention rules before any build starts
- Agreed deliverables, timelines and acceptance criteria, with the compliance assessment owner named in the scope
How we build
- Process, case and decision models built on the Flowable engines, with custom delegates and integrations to your existing systems
- Accessibility checks of custom front ends against the WCAG level your legal obligations require, run during the build
- Security testing of the Flowable REST APIs and application layer, with findings tracked to closure before handover
How we hand over
- Deployment in your infrastructure with runbooks for starting engines, deploying process definitions and recovering failed jobs
- Documentation of decision logic, model versions and the audit history your reviewers will use as evidence
- Knowledge transfer sessions so your staff can maintain models, rules and integrations after the engagement ends
How we support
- Ongoing support, upgrades and continuous testing available as a retainer, scoped to your Flowable version and hosting
- Planned upgrade work for Flowable major versions, including the Java, Spring and Jakarta baseline changes in each release
- Regular review of logs, backups and access controls with your compliance and security teams
