Choosing Flowable Spring Boot starters for your application
Choosing a Flowable Spring Boot starter decides which engines, database tables and HTTP endpoints your application carries once it starts. A Java team embedding Flowable has to make this choice before writing any process code, because the starter pulls in the engine modules and the auto-configuration that creates their schema. The starter is the first dependency decision, not a detail to revisit later, so it is worth settling against the processes, cases and decisions the application will actually run.
The Flowable Spring Boot docs describe starters for all engines together, for the REST API, and for each engine on its own: the process (BPMN), CMMN and DMN engines. The all-engines starter suits an application that will use more than one modeling language. A single-engine starter keeps the footprint and table set to what one engine needs, which fits a team running only process models or only decision tables. The REST starter adds the HTTP API for the engines, so confirm whether your front ends or external workers need that API or whether Java calls are enough. The actuator endpoint at /actuator/flowable is for monitoring running processes, so decide early whether operations staff should see it and who can reach it.
Current Spring Boot support is documented for the 4.x line, so check the starter version against your Spring Boot baseline before you pin it. Flowable open source is licensed under Apache 2.0, which applies to the starters as well as the engines. Ask your team to list the engines they will use in year one, then compare that list with each starter's documented modules. Confirm the exact artifacts and their version in the Flowable Spring Boot docs before you add dependencies, because a starter you do not need still creates tables and exposes endpoints.
Which starter fits which Flowable workload
This table compares the all-engines starter, the single-engine starters for process, CMMN and DMN, the REST starter and the actuator starter. Read each row as one starter, and use the footprint and endpoint columns to judge what it adds to your application. Confirm exact artifact names and table sets against the Spring Boot docs for the Flowable version you run before you pin dependencies.
| Starter | What it loads | Footprint, tables and endpoints | When it fits |
|---|---|---|---|
| All-engines starter | BPMN, CMMN, DMN and event registry engines in one Spring Boot application | Largest footprint. Creates the table sets for every engine enabled. No REST endpoints unless the REST starter is added | Single application that needs several engines and wants one configuration and one schema |
| Process (BPMN) engine starter | BPMN engine and its Java and Spring APIs only | Smallest footprint for process work. Creates BPMN runtime and history tables, with no CMMN or DMN tables | Workloads that only run BPMN processes, such as approvals or service orchestration |
| CMMN engine starter | CMMN case engine and its Java and Spring APIs only | Adds CMMN tables to the schema. No BPMN or DMN tables are created by this starter alone | Case-driven work where stages, sentries and milestones drive the flow |
| DMN engine starter | DMN decision engine and its Java and Spring APIs only | Adds DMN tables for deployed decision models. Lightest engine when rules run inside another application | Decision tables called from code, processes or cases without a process runtime |
| REST starter | Flowable REST API layered on the engines enabled in the same application | Adds HTTP endpoints for the engines loaded. Expose it only behind your gateway and authentication controls | Clients in other languages or front ends that call Flowable over HTTP |
| Actuator starter | Spring Boot actuator endpoint at /actuator/flowable for monitoring running processes | Adds a monitoring endpoint. Restrict it to operations networks and confirm what it reveals in your environment | Operations teams that need visibility into running processes and health probes |
| Combined starters for a service | Engine starters plus REST and actuator, chosen per deployable service | Footprint and exposed endpoints follow the sum of the starters you add. Schema scope follows the same sum | Teams that split workloads into several services, each loading only the engines it runs |
How starter choice changes footprint, tables and endpoints
Each engine a starter loads brings its own schema and runtime services, so the starter you pick decides how many database tables Flowable creates, how much work happens at startup and which HTTP or actuator surfaces exist. A single-engine starter for process, CMMN or DMN keeps the table set and bean graph limited to what your application calls, while the all-engines starter loads every engine even when only one is used. Before you choose, ask your Flowable Spring Boot specialist or check the Flowable Spring Boot docs for the exact tables each starter creates on your target database, and plan to review those tables with your DBA, since unused engines still need schema creation, backup and upgrade effort.
The actuator starter adds the /actuator/flowable endpoint, which exposes information about running process instances for monitoring. Treat that endpoint as an operational surface: confirm which actuator endpoints your Spring Boot application exposes over the network, restrict them to your monitoring network or authenticated roles, and check whether the process information it returns is acceptable for the environments where it runs. The REST starter adds a separate HTTP surface with the engine's REST APIs, so every REST starter you include needs its own authentication, authorization and network policy, and it should be counted as an API surface in your security review rather than as a convenience.
Several application instances sharing one database must agree on how the async executor works. The async executor coordinates nodes through lock owners and lock expiration times stored in the database, so a node that is misconfigured, or that uses a different starter set and table layout from its peers, can pick up or hold jobs in ways the others do not expect. Keep the starter combination, engine configuration and async executor settings identical across all nodes that share a schema, and make that a checked item in your deployment pipeline. Confirm the approach with your platform team before the first multi-node rollout.
Set up the starter and verify what loaded
This sequence confirms that the chosen Flowable version supports your Spring Boot line, adds only the starters you need, and proves which engines and endpoints are active before any process definition is deployed. Each step ends with a check you can record.
Confirm Spring Boot compatibility for the Flowable version
The platform team checks the Flowable version against the Spring Boot line in use before touching the build file. Flowable 8.0.0 moved to Spring Framework 7 and Spring Boot 4 and does not support Spring Boot 3, so a Spring Boot 3 application needs a Flowable 7.x line or a planned Spring Boot upgrade first. Read the release notes for the version you intend to run and record the pairing in the change ticket. The check is a written note that names both versions and the release notes you read.
Add only the starters your use case needs
The developer adds the starter that matches the scope decided earlier, such as a single process, CMMN or DMN starter, or the all-engines starter when several engines are required. Add the REST or actuator starter only when those interfaces are part of the design. Run a dependency tree build and confirm that the expected starter artifacts appear and that no engine appears that the design did not call for. The check is a clean dependency report that matches the starter list in the design record.
Configure the database type from the supported list
The developer sets the datasource URL, driver and Flowable database type in externalized configuration, choosing from the databases Flowable's configuration documentation lists, such as PostgreSQL, MySQL, Oracle, SQL Server or DB2. For MySQL, confirm the server version is at or above 5.6.4 so timestamps keep millisecond precision. Keep H2 out of anything beyond local testing. The check is that the configuration file names the intended database type and that no credentials appear in source control.
Start the application and read the startup log
The developer starts the application against an empty test schema and reads the startup log from top to bottom. Look for the engine initialization messages, the schema creation or validation result, and any error that stops an engine from starting. If the schema is managed by a DBA with DDL scripts, confirm that automatic schema updates are disabled as intended. The check is a clean startup with no unexplained errors and a recorded list of engines that initialized.
Check which engines and endpoints are active
Using the running application, confirm that each engine you intended to load responds, for example by querying the process, case or decision services or by listing deployments through the Java API. Confirm that REST endpoints exist only if the REST starter was added. Compare the list against the design record and remove anything unexpected from the build. The check is a signed-off table showing each engine, its status and the endpoints that answer.
Confirm the actuator endpoint is reachable only where intended
If the actuator starter is present, request the Flowable actuator endpoint from the intended management network and from an outside network path. The endpoint is meant for monitoring running processes, so the security team should confirm that only monitoring systems can reach it and that unauthenticated access from other networks is refused. Also check the exposure settings for the management port. The check is a documented test result for both network paths, reviewed by security before the starter moves to a shared environment.
Security and operational considerations per starter
Each starter you add changes what your application exposes and who can reach it. The cards below cover the checks that follow from that choice, from HTTP and actuator paths to identity and the contents of the image you ship. Review them together before you pick a starter combination for production.
Map every exposed endpoint
The REST starter publishes the engine APIs over HTTP, and the actuator starter adds monitoring routes such as /actuator/flowable for running processes. Each route is a separate attack surface with its own access rules. List every path your chosen starters register in the running application, then confirm which ones are reachable from networks outside your cluster or load balancer.
Authenticate REST and actuator paths
Decide how callers prove identity before a request reaches the REST APIs and the actuator routes, and confirm that the rule applies to both. Monitoring paths often sit behind a different ingress rule than business APIs, so an unprotected actuator can expose process data even when the REST API is locked down. Test both paths with an unauthenticated request in your staging environment.
Change default accounts before go-live
Demo configurations ship with default user accounts that exist to make first runs easy. Before any shared environment starts, find every account the selected starters or the REST application create, replace its credentials and remove accounts you do not need. Record the change in your deployment checklist so that a promoted image does not carry demo users into production.
Replace the identity service deliberately
The engine ships with its own identity management, and the docs allow replacement by overriding IdmIdentityServiceImpl or implementing the IdmIdentityService interface. An LDAP implementation is provided as a reference. Pick the replacement before you build task assignment rules, because groups and users flow into every candidate and authorization check. Ask your team who owns the mapping from your directory to engine groups.
Keep unused starters out of images
A starter on the classpath brings its auto-configuration, tables and endpoints into the running application, even if no process uses them. Build the production image only with the engines and REST or actuator starters you have decided to run. Compare the dependency tree of each build artifact against your starter list, so that a CMMN or DMN dependency added for a prototype does not ship unnoticed.
Questions teams ask before choosing a starter
Should we start with the all-engines starter for Flowable?
Start with the all-engines starter only if your first release genuinely needs more than one engine. The Flowable Spring Boot docs describe starters for all engines, for REST, and for each individual process, CMMN and DMN engine, so a single-engine starter is a valid choice when the scope is narrow. The all-engines starter brings every engine's tables and beans into the application, which increases footprint and the number of schema objects your DBA must review. Starting narrow and adding a starter later is usually simpler than removing unused engines from a broad first build. Confirm the exact dependency set against the version you plan to ship, because the docs list starters per engine rather than a fixed bundle.
What drives the effort and cost of choosing a starter?
The decision itself is small, but it sets the work that follows. The main drivers are how many engines the first use cases need, whether CMMN or DMN models are in scope, whether you need the REST starter or only embedded Java APIs, and whether you want the actuator endpoint at /actuator/flowable exposed in each environment. Each choice changes the tables your DBA must create, the endpoints your security team must review, and the test coverage your team needs. In a quote, ask who owns the dependency decision, who reviews the generated schema, and what is included in the written scope for the chosen starters. Recurring costs come from keeping starter versions aligned with the Spring Boot baseline over time.
How long does a proof of concept for starter selection take?
No duration figure is supplied for this work, so confirm the timeline in a written scope rather than relying on an estimate. A useful proof of concept builds one representative process, and where needed one CMMN case or DMN decision, on the candidate starters, runs it against your target database, and checks the tables and endpoints that appear. Time depends on how many engines you test, how many databases you target, and whether your team already runs Spring Boot services. Ask a partner to name the deliverables, the test cases and the exit criteria before the work starts so the outcome is clear.
What must our team provide before a starter decision is made?
Your team should provide the first use cases in plain language, the Spring Boot and Java versions already in use, the target database types, and the security requirements for any exposed endpoints. The supported databases listed in the Flowable configuration docs include H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server, so name the one you will run in production. Also supply the identity approach, since the Flowable docs say identity management can be replaced through IdmIdentityService, and the deployment target. Without these inputs, the starter choice is guesswork and the proof of concept will need rework.
Can our own team choose the starters without outside help?
Yes, a capable Spring Boot team can make the starter choice internally, especially when the scope is one engine and the target database is already standard in your estate. The decision becomes harder when you need several engines, a DBA-managed schema, identity replacement, or a clear view of what each exposed endpoint reveals. Use the Flowable Spring Boot documentation as the reference for available starters and the actuator endpoint, and test the choice in a non-production environment before committing. A partner is useful when you want an independent review of the choice or a written plan covering the build, not because the decision requires one.
How does our starter choice affect a later move to Flowable 8?
Flowable 8.0.0 was released on February 27, 2026, and its release notes describe an upgrade to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3. That means a starter layout built on a Spring Boot 3 baseline will need a planned upgrade rather than a version bump alone. Narrow starters with fewer engines usually mean fewer dependencies to move and fewer tables to verify. Also note that Jackson 3 is the default JSON library in 8.0.0 with a Jackson 2 compatibility layer, and JUnit 3 and 4 support was removed, so check your tests and serialization code before upgrading. Confirm the exact starter coordinates for your target release in the release notes.
Which starter choices change the endpoints we must secure?
The REST starter exposes the Flowable REST API over HTTP, and the actuator starter adds the /actuator/flowable endpoint for monitoring running processes. Both need authentication, network controls and logging decisions before they reach any shared environment. Engine-only starters avoid HTTP exposure, but your application may still expose the same data through its own controllers. Ask your security team to review each exposed path and confirm how access is granted, because the engine leaves authorization checks to your application.
How Flowable 8 changes starter decisions
The most important starter decision for a Flowable 8 project is the Spring baseline, because Flowable 8.0.0 requires Spring Framework 7 and Spring Boot 4. The Flowable 8.0.0 release notes state that there is no backward compatibility for Spring Boot 3, so a team that keeps a Spring Boot 3 parent POM cannot simply swap in a newer Flowable starter and expect it to start. Before choosing between the all-engines starter, the single-engine starters for process, CMMN or DMN, the REST starters and the actuator starter, confirm the Spring Boot version of the application, then check that each starter the team plans to use publishes for that version. Read the Flowable 8.0.0 release notes for the exact list of changes before you pin versions.
Two other baseline changes affect the same decision. Flowable 8 uses Jackson 3 as the default JSON library, with a Jackson 2 compatibility layer for code that still depends on Jackson 2 types. Any custom REST resource, serializer, variable mapping or test fixture that touches JSON should be inventoried, because the choice of starter does not isolate it from the change. Flowable 8 also removes support for JUnit 3 and JUnit 4, so teams whose process tests run on those frameworks need a migration plan for their test suites before the starter swap, not after. Ask your team to list every test class that extends an old JUnit base class and every module that imports Jackson directly.
The history of the platform explains why this check matters. The Flowable 7.0.0 release notes say that version 7 moved to Java 17, Spring Boot 3 and Jakarta EE, and that it removed the UI applications as well as the form and content engines. Teams that still rely on any of those removed components will find that they have to build replacements in their own applications, which changes the scope of the work and the starter set they need. Treat the Flowable 8 upgrade as a review of what the application actually uses: confirm which engines are in use, which REST endpoints clients call, and which removed components appear in the current deployment, then choose starters only for what remains.
How DeployOpen scopes Flowable starter decisions
DeployOpen plans and implements self-hosted Flowable inside your own infrastructure, so the choice of Spring Boot starters is settled in a written scope before any code is written. We map each engine, REST endpoint and actuator exposure to the tables, footprint and access rules your environment requires.
How we scope
- We list which engines your processes, cases and decisions actually need before choosing any starter.
- The written scope names the starters, Spring Boot baseline, database types and endpoints to be exposed.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We assemble the chosen starters in a Spring Boot project and confirm which schema tables each one creates.
- We restrict or secure the actuator endpoint and REST surface according to the agreed access model.
- We test startup, auto-deployment and async executor behavior against the database you run in production.
How we hand over
- You receive the dependency configuration, property files and a record of why each starter was included or excluded.
- We document the table set, exposed endpoints and any changes needed when you add or remove an engine later.
- Runbooks cover how to confirm the starter mix on a new environment before it goes live.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover moving to a new Spring Boot or Flowable baseline and re-checking exposed endpoints.
- Ask any partner to confirm the support terms, response expectations and upgrade scope in the written quote.
