What a Flowable implementation involves
Flowable's open source engines cover three modeling standards: BPMN for process execution, CMMN for case management and DMN for decision rules. The engines and their Java and REST APIs are licensed under Apache 2.0, so there is no license fee to pay. The cost of a project is the engineering work around the engines: modeling each process or case, writing service integrations and Java delegates, configuring the database and identity, setting up environments, and testing. Those activities take the same skills and time whether or not a license is paid, so budget them as real effort from the start.
Most projects begin with one of three triggers. The first is replacing manual approval chains that run through email, spreadsheets or shared inboxes, where routing rules and audit trails are weak. The second is moving off a legacy workflow tool that no longer fits the platform or the team's skills. The third is automating a case-based process, such as a claim or onboarding file where the next step depends on what is found along the way, which is a better fit for CMMN than for a fixed sequence. Name the trigger early, because it determines which engine, which integrations and which data you must migrate.
In-house or partner is a question of scope and skills. A team with Java and workflow experience can usually build a first small process on its own, using the Spring Boot starters or the REST application, and learn the engine's patterns along the way. Fixed-scope partner work tends to pay off when several BPMN, CMMN and DMN models, multiple system integrations, identity wiring and dev, test and production environments must all be delivered together and on a date. Ask any partner for a written scope listing the models, integrations, environments and test cases it covers, and compare that list against what your own team can deliver in the same window.
What the work includes
Each card names a scope item that changes cost or duration. Ask for each item to appear in the written scope with its decision recorded.
Engine choice for each process
Each business process is assigned to BPMN for ordered, step-based flows, CMMN for case work driven by events and human judgment, or DMN for decision tables that a process calls. The assignment is recorded per process before modeling starts, because it sets the engine, the model files and the test approach. Ask the partner to show this mapping in the plan.
Deployment model and database
Flowable runs embedded in a Spring Boot or Java application, or as the Flowable REST application called over HTTP. Embedding ties engine upgrades to your release pipeline, while the REST application separates them. In both cases the engine stores runtime and history data in a supported database such as PostgreSQL, Oracle or Microsoft SQL Server, so the plan must name the database, its owner and its backups.
Process and case modeling
Models are built in BPMN and CMMN, with stages, sentries, human tasks and milestones for case work. The scope should list each model by name, with its start events, decision points, timers and human tasks. Cost follows the number of models and their branching, so ask for a model inventory alongside every quote.
Service tasks and delegates
Service tasks call Java delegates, expressions or REST endpoints that reach your systems. Each integration needs an agreed data contract, error handling, retry behavior and credential storage. The scope should list every system, the direction of data flow and who provides test endpoints, since these drive most of the build effort.
Process model test suites
Each process and case model gets automated tests that start instances, complete tasks, and assert variables, decision outcomes and timer behavior. Tests run in the build pipeline against a database that matches your production engine. Ask whether regression tests cover every model or only the critical paths, because this changes the test effort.
Deliverables under a fixed scope
A fixed-scope agreement should name the model files, Java code, configuration, test results, a deployment runbook and a handover session. Each item needs an acceptance criterion. The runbook should cover startup, async executor settings, backups and upgrades. Ask for this list to be written into the agreement before work starts.
What drives cost and duration
Each row names one driver of effort, explains why it moves the estimate, and suggests how the buyer can keep it down before the written scope is agreed.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Number of BPMN processes, CMMN cases and DMN tables | Each model needs design, service task wiring, tests and review. Case models and decision tables add modeling and test work per model. | Limit the first release to the highest-value processes. Reuse subprocess and call activity patterns across models. |
| External systems called from service tasks | Each system adds an API contract, credentials, error handling, retries and test doubles. Event-based or asynchronous calls add more design work. | Use one delegate pattern with shared retry and logging. Confirm which systems the first processes need and defer the rest. |
| Embedded engine or REST application | Embedding the engine in your Spring or Java application means your team builds and deploys delegates with that application. The REST app moves more work into HTTP clients and security configuration. | Pick one model per platform before scoping. Confirm which fits your existing deployment pipeline and team skills. |
| Database engine | Flowable's configuration docs list Oracle and Microsoft SQL Server among supported types. Schema setup, DBA review and any database licensing add steps and cost to the plan. | Use the database your organization already operates and supports. Ask the vendor to confirm licensing terms, and test schema upgrades on a copy. |
| Identity source | Replacing the identity service means implementing IdmIdentityService or overriding IdmIdentityServiceImpl. Mapping groups to candidate users and tasks adds design and test work. | Start from the LDAP reference implementation if your directory fits it. Define the group model before modeling user tasks. |
| Number of environments | Each environment needs its own configuration, database, identity wiring and deployment. Promotion steps and test data for each environment add effort. | Keep environment differences in externalized configuration. Agree the number of environments in writing before the quote. |
| Compliance evidence needs | Assessors may ask for change records, access reviews, audit history and test results for each process. DeployOpen prepares this evidence, and independent auditors assess it. | List the evidence in writing before work starts. Generate test and change records from the build pipeline where possible. |
| Flowable version | Version 8.0.0 moved to Spring Framework 7 and Spring Boot 4 with no Spring Boot 3 compatibility. Version 7.x uses Java 17, Spring Boot 3 and Jakarta EE. | Match the version to your current Java and Spring Boot baseline. Confirm the choice before modeling starts, since a later change touches every model. |
Project phases and their outputs
The sequence moves from an agreed process inventory to a tested, handed-over Flowable deployment, with each phase closing on a named artifact the buyer keeps.
Inventory processes and select engines
DeployOpen interviews process owners and reviews existing documents and systems to list candidate processes. Each process is assigned to BPMN, CMMN or DMN, or to a combination, with reasons. The buyer receives a process inventory listing the chosen engine for each process, the systems each one touches, and the open questions still to answer.
Record the engine and deployment decision
The team decides whether Flowable runs embedded in a Spring Boot application using the official starters, or as the Flowable REST application called over HTTP. The decision also covers the supported database type and the Flowable version and Spring Boot baseline. The buyer receives an architecture decision record that states the options considered and the reasons for the choice.
Design architecture and environments
DeployOpen designs the runtime topology inside your cloud accounts, data centers or air-gapped network, including the database, identity source, networking, secrets handling and separate development, test and production environments. Clustering and async executor behavior are planned here if more than one node is needed. The buyer receives architecture diagrams, environment specifications and a deployment runbook draft.
Model processes and design services
Analysts and engineers model the agreed processes and cases in BPMN, CMMN and DMN and define the service tasks, user task assignments, variables and external calls each model needs. Models are reviewed with process owners until the flow matches the agreed inventory. The buyer receives model files under version control and a service interface specification for each integration.
Build delegates and integrations
Engineers implement Java delegates, expressions, listeners and integrations with your systems, along with the identity mapping and REST security configured in the architecture phase. Code is reviewed and built through the agreed pipeline. The buyer receives source code in the buyer's repository, build artifacts and an integration register describing each connection and its credentials.
Test including regression of models
Unit and integration tests cover delegates and service tasks, and process tests run each model through its main, error and timer paths. Regression tests are kept so that later changes to models or the engine version can be checked. The buyer receives a test report with pass and fail results, the regression suite, and a list of accepted defects with owners.
Go live and hand over
The release is deployed to production under the agreed change process, with a rollback plan and monitoring in place, including the Spring Boot actuator endpoint where it is used. Operators and developers are trained on the runbook. Handover closes when the buyer's team accepts the artifacts in the written scope. The buyer receives the production runbook, monitoring setup, operations documentation and the handover acceptance record.
What teams keep in-house and what they outsource
This table shows who usually owns each part of a Flowable project and the skills each part needs, so you can see which work to staff internally and which to scope with a partner.
| Workstream | Usually owned by | Skills it needs |
|---|---|---|
| Process inventory | Business process owners with the delivery lead | Process mapping, interview technique, knowing which processes are rule-heavy, case-driven or simple sequences |
| Engine selection | Architecture lead, with a partner for the BPMN, CMMN and DMN split | Understanding of BPMN, CMMN and DMN fit, Java and Spring stack choices, embedded versus REST deployment |
| Java delegate and expression development | Internal Java developers, with partner support during build | Java, Spring, transaction and error handling, secure expression design |
| BPMN, CMMN and DMN modeling | Process analysts with partner modelers, reviewed by business owners | BPMN and CMMN notation, DMN decision analysis, Flowable model conventions |
| Integration with identity and line-of-business systems | Partner for the build, internal teams for system access and approvals | Identity protocols, REST and messaging integration, Flowable identity service extension points |
| Test automation | Partner for the framework, internal QA for business acceptance | JUnit, Flowable test support, process-level and decision-table test design |
| Database and deployment operations | Internal platform or database team, with partner runbooks | Operations on the chosen database, Spring Boot deployment, async executor and schema upgrade practice |
| Business process ownership | Named business owners, always internal | Domain knowledge, authority to approve rule changes in DMN tables and process logic, change control |
What usually goes wrong
Most Flowable delays and rework come from a small set of decisions made early or skipped during testing. Each pattern below has a specific check that can be done during scoping.
Wrong modeling paradigm
Teams model a predictable, ordered sequence as a CMMN case, or model unpredictable, knowledge-driven work as a BPMN process. Both choices produce diagrams that are hard to change later. Before modeling, list each process and ask whether the path is fixed or decided by the people doing the work at run time. Review that choice with the people who will maintain the models.
Engine version without framework check
Flowable 8.0.0 requires Spring Boot 4 and does not support Spring Boot 3, so an application on Spring Boot 3 cannot adopt this release without a framework upgrade. Confirm the Spring Boot and Spring Framework baseline of your application before choosing a Flowable version. Plan the framework upgrade as a separate, scheduled workstream with its own cost and testing.
Mixed Jackson versions in custom code
Flowable 8.0.0 uses Jackson 3 as its default JSON library and provides a Jackson 2 compatibility layer. Custom delegates, listeners and REST endpoints that import Jackson 2 types next to engine objects can fail at run time or serialize data differently. Inventory every JSON library import in custom code, choose one major version per module, and test serialization of process variables and REST payloads.
Relying on removed UI applications
Flowable 7.0.0 removed the open source UI applications, so there is no bundled task inbox or process administration screen to start from. Teams that assume those screens will still be available often find the task UI missing late in the project. Plan the task UI as a named deliverable with owners, users and a build estimate, and confirm which commercial product, if any, your organization would consider.
Service tasks without timeouts
A service task that calls an external system can wait indefinitely if the call has no timeout, which ties up process resources and delays the instance. Set timeouts on every HTTP client and connector that delegates use. Route failures through error handling in the model, such as error boundary events, with defined retry behavior. Document what happens to the instance after the final failed attempt.
Testing only the happy path
Tests that run only the approved route miss timers, rejected approvals, failed service calls and compensation paths, which is where production surprises tend to appear. Write tests for each gateway branch, each boundary event and each error path. Run the suite against the same database type as production, since database behavior and asynchronous job handling can differ from an in-memory test setup.
How the work differs by starting point
A new build has the most decisions to make up front, so the plan should settle the Spring Boot baseline and starter set before modeling starts.
- Baseline: Flowable 8.0.0 is built on Spring Framework 7 and Spring Boot 4 and does not support Spring Boot 3. Teams on Spring Boot 3 should plan for the 7.x line or upgrade Spring Boot first.
- Starters: Include the starters for the engines you need, and add the REST starter only if external clients will call the engine.
- Database: Confirm the target database against the supported list in the configuration docs, including the MySQL version rule.
- Dependencies: In an air-gapped or on-premises build, dependency sourcing changes. Confirm how build artifacts are mirrored and approved in your own environment.
- Cost driver: Most effort sits in process modeling and service integrations, not in the starter setup.
An embedded build inside an existing application depends on the container and Jakarta baseline you already run, so the plan starts with a compatibility check.
- Container: Flowable can be embedded as a JAR in servlet containers such as Tomcat or Jetty, in Java EE servers, or in plain Java SE applications.
- Baseline: Version 7 moved to Java 17, Spring Boot 3 and Jakarta EE. An older runtime needs a platform upgrade before the engine can be added.
- Existing code: Map which parts of the application will call the engine and which transactions and connection pools they share.
- Packaging: Decide whether the engine ships inside the existing archive or as a separate service, and confirm how deployment and rollback work for each option.
- Scope split: When platform work is needed before the engine starts, ask the partner to scope that work as a separate item so it does not hide inside the process build.
Running the Flowable REST application suits teams whose clients are not Java code in the same process, such as front ends, other services or low-code tools.
- Interface: The UI applications were removed in version 7, so the REST API is the interface your clients use, and your team builds the task screens.
- Security: Plan authentication and authorization for every endpoint before any client connects. Spring Security with OAuth2 or OpenID Connect is a common path, so confirm the approach with your identity team.
- Client contracts: Document request and response shapes for each client and version them, so one change does not break every consumer.
- Operations: Size the REST tier and the shared database separately, and plan how the async executor behaves when several nodes run.
- Cost driver: The number of clients and integration patterns moves effort more than the engine does.
A replacement project starts from an existing process estate, so the plan separates data movement from application rework.
- Data: Flowable's engineering blog states that Camunda 7 and Activiti data can be migrated to Flowable in place, including active process instances and history. Treat the data path as its own work item.
- Readiness: The same blog describes the free Flowable LEAP tool, which reports ahead of time what a migration involves. Ask for that report before estimating rework.
- Application code: BPMN XML extensions, Java delegates and in-flight instances each need their own review.
- Details: The sibling migration topic covers in-place data migration, the LEAP report, database copy testing and cutover.
- Confirm: Check your source versions and migration steps against current Flowable documentation in your own environment.
What you need to provide
The fastest way to a firm, fixed-scope Flowable quote is to hand the scoping team a short set of inputs before discovery starts. Each item below removes a question that would otherwise be answered during build, where it is far more expensive to resolve. Ask for these in writing, with a named owner for each, before the first scoping call.
Start with named business owners for each process, plus a process inventory or the current procedure documents. Owners decide which steps are standard, which exceptions are acceptable and who signs off on the BPMN or CMMN model. Procedure documents show what the team does today, so modelers do not have to reconstruct it from interviews. Without them, the usual result is a model that matches the document nobody follows, and a change request later when the business corrects it.
For DMN decision tables, provide sample data and the decision inputs with their expected outputs, drawn from real past cases where possible. Test cases from production history expose boundary values, such as rounding rules or date cut-offs, that a written policy often leaves out. For each integrated system, supply the API specifications, a test environment and test credentials. Missing credentials are a common cause of delays, because service tasks cannot be verified end to end until they work.
Confirm the target database and how it will be provisioned, since Flowable supports several database types and the choice affects schema setup, backups and the high availability design. Also provide the identity source and group structure, because candidate users and groups drive task routing. Finally, confirm the target Java and Spring baseline. Flowable 8.0.0 requires Spring Boot 4 and does not support Spring Boot 3, so an existing Spring Boot 3 estate changes the plan. Name one decision maker who signs the written scope, so that changes are approved against a document rather than negotiated informally.
Frequently asked questions
What drives the cost of a fixed-scope Flowable project?
The number and complexity of process and case models, the service integrations behind them, and the identity and data setup decide most of the effort. Each BPMN process, CMMN case and DMN decision table needs modeling, Java delegates or expressions, tests and deployment. Integrations with your systems, a custom task interface (the open source UI applications are no longer included in Flowable 7 and later), and migration from Camunda 7 or Activiti add scope. Hosting, database, monitoring and upgrade work recur after go-live. Ask any quote to list each deliverable, the assumptions about your environment and what is excluded.
How long does a Flowable implementation take and why is no duration quoted upfront?
Duration depends on the written scope, so no timeline is quoted until the process inventory and integration list are agreed. The main variables are how many processes and cases are in scope, how many systems each one calls, how clean your identity and data sources are, and how quickly your reviewers can approve models. Timelines are set in the fixed-scope agreement with deliverables and milestones. Before requesting a quote, list your processes, their decision logic and the systems they touch so the estimate reflects the actual work.
Can our own developers build a Flowable implementation without a partner?
Yes, a team with Java and Spring experience can build on Flowable, because the engines are open source and documented. The harder questions are process design, governance of models, testing across BPMN, CMMN and DMN, and operating a clustered deployment with async executor locking and database backups. Check whether your team has owned a workflow engine in production before, who will maintain models after go-live and how upgrades will be tested. A partner can take on a defined part of that work, such as the first build or a migration, while your team keeps ownership.
Does the Apache 2.0 license mean Flowable has no fees?
The engines carry no license fee under Apache 2.0, but running them still costs money. Your budget covers developers, the database, hosting in your cloud or data center, monitoring, backups, upgrades and any support contract you choose. Flowable also sells commercial products, including Flowable Work, Engage, Orchestrate and Design, which add low-code modeling, visual debugging and governance under their own terms. Ask any quote to separate one-time build effort from recurring operating cost, and confirm current licensing terms with Flowable before deciding.
Should each process use BPMN, CMMN or DMN?
Use BPMN for work with a defined sequence of steps, CMMN for case-driven work where the order depends on events and human judgment, and DMN for rules that map inputs to decisions. Most projects combine them: a BPMN process calls a DMN table for eligibility, and a CMMN case hands a stage to a BPMN process. Decide per process in a workshop, using the sequence, how often the logic changes and who makes the decisions. Record the choice and the reason so reviewers can challenge it later.
Which Flowable version should we start a new project on?
For a new project, evaluate Flowable 8.0.0 first, which was released on February 27, 2026. It moves to Spring Framework 7 and Spring Boot 4, drops support for Spring Boot 3, makes Jackson 3 the default JSON library and removes JUnit 3 and 4 support. If your application runs on Spring Boot 3, plan that platform upgrade as part of the project. The supported database types include H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server. Confirm the current patch release and your database versions with Flowable before you fix the plan.
How DeployOpen scopes, delivers and hands over Flowable work
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, and Flowable work follows the same written-scope method. The cost of a Flowable project is set by the decisions made at the start, so we agree those decisions in writing before build work begins.
How we scope
- We map each business process to a BPMN process, CMMN case or DMN decision table before estimating build effort.
- The written scope names the engines, the Spring Boot or REST deployment model, and the database type you run.
- We list every service integration, identity source and event channel, since these are the largest drivers of build effort.
How we build
- We model processes and cases in your chosen notation, then implement delegates, service tasks and listeners in your Java stack.
- We test process models against automated test suites and a database copy that matches your production database type.
- We configure the async executor and job locking for your planned node count, so timers and jobs behave correctly under load.
How we hand over
- We deliver process models, delegate code, configuration and runbooks in your version control and documentation.
- We run knowledge transfer sessions so your engineers can change models, deploy releases and read engine history.
- We agree acceptance criteria in the written scope so handover is tested against defined outcomes, not assumptions.
How we support
- Ongoing support, upgrades and regression testing of process models are available as a retainer, with scope agreed in writing.
- Upgrade planning covers version changes such as the Flowable 8.0.0 move to Spring Boot 4, which we confirm against your own stack.
- Support terms, response expectations and included hours are set in the retainer agreement, and we confirm them for your environment during scoping.
