What a Flowable implementation involves
Flowable provides process (BPMN), case (CMMN) and decision (DMN) engines written in Java and released under the Apache License 2.0. The engines run embedded in a Java application, usually Spring Boot, or as a standalone REST service, and keep their state in a relational database. They suit onboarding, claims, lending approvals and exception handling, where every step, approval and deadline has to be traceable.
Installing the engine is a small part of the work. Most effort goes into mapping the process with the people who run it, choosing a model type for each part, writing the Java code behind service tasks, connecting core systems and building the screens people use to work their tasks.
Since Flowable 7.0 the open-source release concentrates on the three engines and their APIs; the UI applications, bundled modeler and form and content engines were removed. Flowable's commercial products, including the Flowable Design modeler, build on the same engines. An open-source build therefore needs a modeling tool and a task UI of your own. Flowable Open Source 8.0.0, released in February 2026, moved to Spring Boot 4 and Spring Framework 7.
How an implementation runs
Stages overlap, and each ends with something the next stage can check.
| Stage | Work | Output |
|---|---|---|
| Discovery | Walk through the process with the people who run it: triggers, handoffs, approvals, exceptions and systems touched. | A process inventory with owners and known exceptions. |
| Model design | Draft BPMN, CMMN and DMN models and agree naming, variables and error handling with process owners. | Reviewed models in Git with a data contract for each. |
| Build and test | Write delegates and integration code, build the task UI, and test against core systems, including failures and retries. | A deployable application with tests for each model path. |
| Rollout | Start with one process or business unit and run old and new paths in parallel where needed. | A cutover plan with rollback steps. |
| Enablement | Train developers on APIs and testing, analysts on modeling conventions, and operators on jobs and incidents. | A modeling guide and runbooks. |
Design decisions to settle early
These choices shape the code, the database and who operates what.
Embedded or standalone
Embedding the engines in a Spring Boot service keeps delegates, transactions and domain code in one deployable. A standalone REST service suits several consuming applications, with external worker tasks that services in any language poll and complete.
Task and case UI
The open-source engines expose task, case and history APIs with no end-user interface. Build a front end, embed tasks in an existing portal, or license a Flowable product.
Identity and authorization
Map candidate users and groups in models to groups from your identity provider, and decide where task authorization is enforced.
History level
History levels run from none to full. Higher levels give a fuller audit trail and grow the history tables faster, so agree level and retention with compliance owners.
Database
Flowable supports PostgreSQL, MySQL, Oracle, SQL Server and DB2, with H2 for tests. Choose one your team already operates with backups and failover.
Choose the model type for each part of the work
Processes with a defined flow: user and service tasks, gateways, timers, messages and error boundaries. Mark long or remote calls as async so the async executor runs them and database transactions stay short.
Cases where people decide the next step: stages, milestones, sentries and discretionary tasks. CMMN fits investigations, complaints and complex claims, and a case can start BPMN processes for its structured parts.
Decision tables for eligibility, routing, limits or risk scoring. Version each table with its test cases so rule owners can change rules through a reviewed release.
Channel and event definitions let models start or continue on messages from JMS, Kafka or RabbitMQ, and send events out. Agree payload contracts and correlation keys with each topic owner.
Building custom logic around the engines
Flowable's extension model is plain Java and Spring. Most custom work falls into four areas.
Service tasks and delegates
- JavaDelegate classes or Spring beans called from expressions.
- Idempotent delegates, since failed async jobs are retried.
- External worker tasks when logic lives in another service.
- Business code in tested Java, with few script tasks.
Listeners and interceptors
- Execution and task listeners for assignment and notifications.
- Engine event listeners for monitoring and outbound events.
- Process and case end interceptors, added in Flowable 8.0.
Integrations
- Core banking, policy, CRM and document systems over REST or messaging.
- Error boundary events and compensation for failed remote calls.
- Correlation rules so inbound messages reach the right instance.
Testing
- JUnit 5 tests with Flowable's test support (JUnit 3 and 4 support was removed in 8.0).
- A test for each model path, including timers and escalations.
- Decision table tests from cases supplied by rule owners.
Migrating from Camunda 7 or Activiti
Camunda 7 Community Edition reached end of life in October 2025 with its final 7.24 release, and no longer receives security patches. Since version 8.6, Camunda 8 Self-Managed requires a license for production use. Flowable is one alternative, since Flowable and Camunda 7 both descend from Activiti and share much of their BPMN vocabulary.
Flowable documents an in-place path for Activiti 5 and Camunda 7 databases: point Flowable at a copy of the database, let the first start update the schema, and enable the flowable5-compatibility layer so in-flight instances keep running. Camunda extension attributes, class references, delegates using Camunda APIs and external task workers still need rework.
When instances are short-lived, a side-by-side cutover can be simpler: new instances start on Flowable while existing ones finish on Camunda 7. Either way, rehearse on a copy of production data and test parallel joins, boundary events, timers in flight and partially completed branches.
Hosting, high availability and security
Flowable nodes share one database, so availability comes from two or more nodes behind a load balancer plus database failover. Each node's async executor locks jobs as it acquires them, and expired locks are reset so another node can take the work. Alert on the dead letter job table, where jobs land after their retries are used up.
Keep databaseSchemaUpdate set to false in production so schema changes happen only in a planned upgrade, and plan history retention and cleanup before go-live.
The Flowable REST application uses HTTP Basic authentication and checks a REST access privilege per user. Run it only behind HTTPS, change the bootstrap admin password, and limit who can deploy models, since models can carry scripts that run inside the engine.
For staff-facing applications, put Spring Security in front of the engine APIs with OIDC or SAML from your identity provider, such as Keycloak or Microsoft Entra ID, and map its groups to the candidate groups used in models.
Model versions, upgrades and backups
What happens to running instances when a model changes?
Deploying a model with the same key creates a new version. New instances use it and running instances stay on the version they started with. Flowable's process instance migration API can move instances to a new version with activity mappings and a validation step. Keep models in Git and promote them through a pipeline.
What do we back up?
The database holds definitions, running state, jobs and history, so its backups and point-in-time recovery are the core of recovery. Keep models, configuration and code in version control, and rehearse a restore.
How do engine upgrades work?
Read the release notes, run the schema upgrade against a copy of production, and test models and custom code. Flowable 8.0 dropped Spring Boot 3 and made Jackson 3 the default, so scripts that call JsonNode methods may need changes. Flowable 7 and later require Java 17 or newer.
Flowable implementation questions
Do we need a commercial Flowable license?
Not for the engines, which are Apache-2.0. A license becomes relevant for Flowable's commercial modeling, work interface, monitoring or vendor support. We can help you compare a custom UI with a licensed product.
Where should we start?
Pick one process with clear owners and well-understood exceptions, build it end to end with its UI, integrations and monitoring, and use it to settle conventions.
Does Flowable help with audit evidence?
History records who did what and when, which supports evidence for SOC 2, ISO 27001 or DORA controls. DeployOpen can assess the implementation against those requirements; we do not issue audit reports or certifications.
Scope and handover
Effort depends on the number of processes and cases, decision logic, the systems to integrate, whether a task UI has to be built, whether Camunda 7 or Activiti instances must be migrated, and availability targets. Integration and UI work usually take longer than engine setup.
DeployOpen runs discovery workshops, builds models, delegates and integrations, sets up the engines in your infrastructure with high availability, SSO and hardening, plans migrations and trains your teams. Handover includes models and code in your repositories, the modeling guide, test suites, the deployment pipeline, runbooks for jobs, incidents and upgrades, a restore test record and named owners for process behavior, code and the platform.
