What Flowable customization involves
Flowable's open source engines ship without a bundled process designer or end-user interface, so customization means writing Java code around the engines and testing it. The work typically covers Java delegates and expressions that run inside BPMN service tasks, custom service task implementations, event registry channels that receive and emit events, execution and task listeners, and REST extensions that expose your own endpoints beside the engine's REST API. Each of these is code your team owns, versions and tests.
Most customization starts from one of four triggers. Processes need to call internal systems such as ERP, core banking or case management services. Events arrive from Kafka or other brokers and must start or correlate process instances. Domain rules are too involved for a DMN table and need Java. Finally, the open source UI applications were removed in the Flowable 7 release, so teams that need people to work on tasks must build a task interface of their own or choose a commercial product. Confirm which of these apply before estimating the work.
Short answer on in-house versus partner: teams with strong Java and Spring skills can build much of this themselves, especially delegates and listeners that follow established patterns. Teams without that experience, or teams facing a tight deadline, often bring in a partner for the first build, then take over maintenance and extension once the patterns are in place. Ask any partner to show how the code is structured, tested and handed over.
What the work includes
Each workstream extends the Flowable engine at a defined extension point and ends with a deliverable in your repository or runbook set. The exact channel adapters and their options should be confirmed against the Flowable release you target.
Java delegates and expressions
Java delegates and expressions carry the domain logic that a BPMN model calls at a service task. Each class or expression is written against the Flowable APIs, covered by unit tests that run without a live engine where possible, and reviewed for what it can reach. Ask for the test scope and the expression language rules in writing.
Custom service tasks and error handling
Custom service tasks wrap calls to your systems, and their failure paths decide whether a process retries, routes to a boundary event or stops for an operator. Each task is documented with its inputs, outputs, retry behavior and the BPMN error codes it raises. Confirm how retries interact with the async executor before go-live.
Event registry channels for brokers
Event registry channels connect Flowable to brokers such as Kafka, with inbound and outbound mapping that translates payloads into event definitions and back. Each channel gets a documented configuration covering topics, keys, serialization and error handling. Confirm the supported adapters and their options against the Flowable release you target before design starts.
Execution and task listeners
Execution and task listeners fire on lifecycle events such as process start, activity completion or task creation, which makes them a common place for audit records and side effects. Each listener is scoped to specific events, is idempotent where it writes externally, and is listed in a runbook. Check listener order and transaction boundaries during testing.
Custom REST endpoints on Flowable APIs
Custom REST endpoints expose domain operations on top of the Flowable Java APIs, for example starting a process with validated business keys or querying tasks by your own attributes. Each endpoint is delivered with its contract, authorization rules and integration tests. Authentication design should be agreed with your identity model before endpoints are built.
Custom task UI on the engine APIs
Because the open source UI applications are no longer part of Flowable 7 and later, a custom task UI calls the engine through its APIs to list, claim and complete tasks. The deliverable is the application, its API integration layer and a runbook covering deployment and access control. Scope the screens, roles and browser support as part of the fixed-scope agreement.
What drives customization cost and duration
This table lists the factors that change how much work Flowable customization takes, why each one raises effort, and one practical way to keep it manageable.
| Driver | Why it raises effort | How to keep it down |
|---|---|---|
| Number of extension points | Each Java delegate, service task, execution or task listener is code you must write, test, version and upgrade alongside the BPMN models that call it. | Limit custom code to a small set of delegates with documented input and output contracts, and reuse one pattern for all of them. |
| External systems and brokers | Every system or Kafka topic adds authentication, error handling, retries, idempotency and monitoring, and each one needs test doubles or a shared test environment. | Inventory connections before design, route them through one integration layer, and confirm which event registry channels your brokers need. |
| Event volume and ordering | High throughput and strict ordering push design toward partitioning keys, deduplication, correlation keys and async executor tuning, which take longer to prove under load. | State the expected peak rate and ordering rule in writing, and agree which flows genuinely need ordering before modeling starts. |
| Depth of domain logic in Java versus BPMN | Rules pushed into Java are harder for process owners to read and change, while heavy BPMN scripting is harder to test and secure. | Keep routing in BPMN and DMN decision tables, and keep calculations in tested Java services called from delegates. |
| Task UI scope | Building your own task UI means screens, forms, validation, roles, pagination, and offline or mobile behavior each need design and testing, since the open source UI apps are no longer included in version 7 or later. | Start with one standard task list and form pattern reused across processes, and defer mobile or offline needs to a later phase. |
| Identity and permission model | The UI and REST calls must respect candidate users, groups and data ownership, so mapping from your identity provider and access tests add work. | Decide group mapping and task visibility rules early, and implement them once in a shared identity service. |
| Test coverage expected by your change process | Teams that require unit, integration and process-level regression tests for every model change need more build time, test data and CI capacity. | Agree a test standard per process type, and automate process model tests so they run on every change. |
| Number of environments | Each environment needs its own database, configuration, secrets, broker topics and deployment of process definitions, and migrations must be rehearsed in each. | Keep environment differences in configuration rather than code, and confirm how many environments your approval process truly requires. |
How the project runs
The sequence moves from understanding the process models to a tested, documented set of extensions that your team can operate after handover.
Discover process models and extension points
We review your BPMN, CMMN and DMN models, the places where they call out to code, and the systems each call reaches. The output is an inventory of delegates, service tasks, event channels, listeners and custom endpoints, each marked with its owner and whether it is needed at launch. Your team confirms the inventory before any code is written.
Write a contract for each extension
Every delegate, service task and event channel gets a short written contract covering its inputs and outputs, the variables it reads and writes, the error behavior (retry, compensation, or escalation to a human task), and its idempotency expectations. Contracts are reviewed with your process owners and integration owners. The output is a signed-off contract set that drives the build and the tests.
Build against a pinned Flowable version
Development starts on a pinned Flowable release, the same version that will run in production, with a local or test database of the type you use in production. Custom code is kept in your own repository with build and dependency configuration under version control. The output is a build that starts, deploys the process models and runs the unit tests of each extension on every commit.
Run integration tests with the broker and target systems
Each event channel, such as a Kafka topic, and each target system is exercised in a shared test environment that mirrors production configuration. Tests cover successful paths, timeouts, malformed messages, duplicate delivery and downstream failures. The output is a test report showing how each contract behaves under those conditions, with open defects logged against the contract they break.
Build the task UI and run acceptance testing
Because the open source Flowable UI applications are no longer part of the 7.x and 8.x line, the task interface is built as your own application over the REST API. Business users run the agreed scenarios against the process models and sign off each one. The output is a written acceptance record linked to the scenarios, with any changes made before go-live.
Hand over runbooks and the test suite
Your team receives runbooks for deployment, job and event troubleshooting, database maintenance and rollback, along with the automated test suite and a guide to running it. Knowledge transfer sessions walk your engineers through the code and the contracts. The output is a handover record that names the people who now own each extension and the tests that protect them.
What your team keeps and what a partner can take
This table shows each part of a Flowable customization, who usually builds it, and the skills it requires, so you can decide which parts stay with your team and which a partner can carry.
| Work part | Usually done by | Skills required | Who keeps it after handover |
|---|---|---|---|
| Domain logic in Java delegates | Partner builds, your engineers review | Java and Spring, Flowable engine APIs | Your engineers own the code; process owners confirm the rules |
| Process model changes (BPMN, CMMN, DMN) | Your process owners with engineers | BPMN and DMN modeling, Flowable engine APIs | Process owners keep the business rules and decision tables |
| Event channel configuration for Kafka or other brokers | Partner configures, your platform team operates the broker | Kafka or broker operations, Flowable event registry | Your platform team keeps topics, access and retention |
| Custom REST endpoints | Partner builds, your engineers extend | Java and Spring, Spring Security, REST API design | Your engineers own versioning and access rules |
| Task UI with access control | Partner builds the first version | Front-end development, access control, Flowable REST API | Your product or front-end team owns the UI roadmap |
| Automated tests for process models and delegates | Partner builds reusable tests and patterns | Test automation, Java, Flowable test utilities | Your team keeps and extends the test suite |
| Deployment pipeline | Partner sets up, your DevOps team runs | CI/CD, container and database migration tooling | Your DevOps team owns pipeline changes and releases |
| Ongoing ownership and upgrades | Your team, with optional partner retainer | Flowable release tracking, dependency updates, regression testing | Your team owns upgrades; a retainer can cover them if you choose |
What usually goes wrong
Most Flowable customization problems come from a small set of design choices made early, often before anyone has tested a process under retries, upgrades or a second node. The cards below name each failure point and the check or design step that prevents it.
Business logic hidden in delegates
Rules such as pricing, eligibility or routing end up inside Java delegate classes that process owners cannot read or change. Keep decision logic in DMN tables where the model supports it, and keep delegates thin. Review each delegate with the process owner against the BPMN diagram, so the model still describes what the system actually does.
Expressions that depend on mutable state
Gateway conditions and listener expressions that read values which change between evaluation and use can route a process differently on replay or on a second node. Restrict expressions to process variables set at known points, and test each gateway with boundary values. Confirm which variables a script task or expression may read and write before go-live.
Non-idempotent service tasks
When the engine retries a failed service task, a payment, email or ticket call made before the failure may run a second time. Pass a stable idempotency key derived from the process instance and activity, store the result of each external call, and check that key before calling out again. Confirm the retry count and retry behavior for your async jobs.
Event channels without a key strategy
Event registry channels for Kafka and other brokers can deliver out of order or more than once, and a consumer that assumes otherwise will corrupt process state. Define the partition key and the correlation key before building the channel, make inbound handlers tolerant of duplicates, and test redelivery with a deliberately repeated message.
REST extensions without an authorization model
Custom REST endpoints added to the Flowable REST application or Spring Boot service can expose process data to callers who should not see it. Map each endpoint to a role or group, enforce the check on the server, and test it with a user who lacks access. Align these rules with the identity integration rather than with the UI.
Task UI built on internal APIs
A custom task interface that calls undocumented engine internals breaks silently when the engine changes. Build the task UI against the public Java and REST APIs, and record which endpoints and services it depends on. Plan this work now, because Flowable 7.0.0 removed the open source UI applications from the distribution.
Extensions tied to one Flowable version
Listeners, delegates and custom endpoints written against one major version can fail after an upgrade, as the move to Flowable 8.0.0 with Spring Framework 7 and Spring Boot 4 showed. Pin the Flowable version in your build, run contract tests on your extensions for each candidate upgrade, and keep a regression suite of process models that runs on every change.
How the work changes by starting point
A new Spring Boot application using the official Flowable starters gives the most freedom in code structure, because delegates, listeners and event registry channels can be packaged as ordinary Spring beans in the application module.
- Code structure: Keep delegates, expressions and listeners in a dedicated package, registered as beans so the engine resolves them by name without extra wiring.
- Starters: Confirm the starter set for each engine you use, and confirm Spring Boot 4 compatibility for the Flowable version you select.
- Testing: Run engine tests against an in-memory or containerized database that matches your production vendor, so the schema and job behavior are exercised.
- Deployment: Ship extensions inside the same deployable artifact as the engine, which keeps versions aligned but ties extension releases to application releases.
- Next steps: See the Flowable Spring Boot integration and Flowable upgrades and support topics for setup and version management.
An existing Java SE or servlet deployment without Spring embeds the engine as a library, so customization is done through configuration and Java classes wired at startup rather than through Spring injection.
- Code structure: Register custom delegates and listeners through the engine configuration, and keep the configuration in one place so startup order is predictable.
- Packaging: Confirm which Flowable JARs your container already provides, and avoid duplicate versions of the engine or Jackson on the classpath.
- Testing: Build integration tests that boot the engine the same way the production container does, including the database driver and connection pool settings.
- Deployment: Plan how new extension JARs are added to the server, whether by redeploying the web application or by updating a shared library directory.
- Next steps: See the Flowable implementation plan and cost topic for embedding decisions and the Flowable security hardening topic for classpath and script controls.
When Flowable already runs as the REST application, the engine is a separate service and extensions must live outside it, because you cannot add Java classes to the running engine.
- Code structure: Build the extension as a separate service that calls the REST API, or as a custom REST endpoint in your own application that wraps engine calls.
- Event handling: Use event registry channels for asynchronous integration instead of adding listeners inside the engine, and confirm the broker and channel setup with your team.
- Testing: Test the external service against a running engine instance, and version the API contract so engine upgrades do not silently break callers.
- Deployment: Release the extension on its own schedule, but coordinate the engine and extension versions because they are no longer packaged together.
- Next steps: See the Flowable SSO and identity integration topic for securing REST calls between services.
Extension work that follows a migration starts from existing delegates and BPMN XML, so the task is adapting code that was written for another engine rather than designing new extension points.
- Code structure: Map each Camunda 7 or Activiti delegate and listener to the Flowable equivalent, and remove any dependencies on classes that Flowable does not provide.
- BPMN changes: Review extension elements and vendor-specific attributes in process XML, since these are the most common points where behavior shifts.
- Testing: Run in-flight instances and history from a copy of the production database through the migrated extensions before cutover.
- Deployment: Sequence the extension release with the data migration so that instances start on code that understands their current activities.
- Next steps: See the Camunda 7 to Flowable migration topic for the in-place data migration, the LEAP report and cutover steps.
On an air-gapped or restricted network, the customization work depends on what can reach the engine and what can be downloaded to build it, so access planning comes before code design.
- Broker access: Confirm which Kafka or other broker endpoints the engine and extension services can reach, and how credentials are delivered without external secret services.
- Build tooling: Mirror the Maven or Gradle repositories, the Flowable artifacts and their transitive dependencies into an internal repository, and verify the mirror before build day.
- Testing: Run test suites in the restricted environment, because tests that pull external containers or services will fail there.
- Deployment: Transfer signed artifacts through your approved media process and record the checksums of each release.
- Next steps: See the Flowable security hardening topic for dependency controls and the Flowable upgrades and support topic for planning updates into the restricted network.
What you need to provide
Most of the delay in a Flowable customization project comes from inputs that exist on paper but have no owner. Before work starts, the client should name a person responsible for each item below and confirm that person can make decisions without waiting for a committee. The team needs the BPMN, CMMN and DMN models in version control, with the current production versions tagged and a named owner for each process, case and decision table. Models that live only in a modeler on someone's laptop slow every change and make regression testing guesswork.
For event registry channels and service tasks, the client supplies broker topics or event schemas, sample payloads and a named owner for each topic. Where delegates call internal systems, the client provides API specifications or supervised access to those systems, plus a test environment that behaves like production. The task UI needs identity and role information: which groups map to candidate users, which roles can claim or reassign tasks, and how those roles are sourced from your identity provider. Ask for an export of real group memberships with personal data removed, so role mapping is tested against reality.
Three decisions are often left open and should be settled early. First, who approves business rule changes in DMN tables, and whether that approval must be recorded. Second, who owns the build and release pipeline, including the route from a Git commit to the non-production environment. Third, a non-production environment with a database the team can reset whenever a test run needs clean data. Confirm with your platform team the exact database engine and version you will run, since the supported list in the Flowable configuration documentation is broad and your choice affects test setup.
Common questions about Flowable customization
Can our in-house Java team build Flowable delegates and listeners without a partner?
Yes, a team with solid Java and Spring experience can write delegates and listeners, because they are ordinary Java classes that the engine calls during process execution. The harder parts are understanding how transactions, asynchronous jobs and retries interact with your code, and testing each delegate against the process model it belongs to. Before deciding, confirm who will own the code after go-live, whether anyone on the team has run Flowable in a production-like environment, and how much regression testing your process models need. A partner is most useful when the scope is large, the timeline is fixed, or no one has operated a workflow engine before. Effort depends on the number of tasks, the integrations behind them and test coverage, so ask for a written scope that breaks these down.
What drives the effort of a custom task UI in Flowable?
The main drivers are how many task types the UI must handle, how dynamic the form logic is, and how the UI authenticates users and reads task and process data. Flowable 7.0.0 removed the open source UI applications, so your team builds its own screens against the engine's Java and REST APIs. Each task type needs a form model, validation, permissions and error handling for claiming, delegation and reassignment. Browser support, accessibility testing and integration with your identity provider add further work. Ask for the UI scope to be separated from the engine work in the written scope, and confirm which decisions, such as front-end framework and hosting, your team has already made.
How do Kafka event channels differ from synchronous service calls in Flowable?
An event registry channel sends or receives events asynchronously through a broker such as Kafka, while a service task call waits for a response inside the process step. Events decouple the process from the consumer, but they raise questions about ordering, duplicate delivery and failure handling that a synchronous call avoids. Decide first which steps must complete before the process continues, what happens when the broker is unavailable, and who owns the topic schema. Those answers determine whether a step should wait for a reply, emit an event, or do both. Broker design, including partitions, retention and access control, is scoped separately in the Kafka implementation work.
Do custom REST endpoints need a separate security review?
Yes, treat each custom endpoint as new attack surface. An endpoint added to the Flowable REST application or a Spring application runs under your authentication and authorization rules, so it needs its own review of who may call it, which process variables it can read or change, and how input is validated. Confirm whether the endpoint reuses the existing security configuration or sets up its own, and whether its actions appear in logging and audit history. Reviewers usually check authorization for each operation, input handling and dependency versions. Flowable 8.0.0, released on February 27, 2026, moved to Spring Boot 4 and Jackson 3, so the review should cover the versions your build actually uses.
How do we keep Flowable extensions working through upgrades?
Keep extensions behind stable interfaces, pin dependency versions in your build, and run the process test suite on every upgrade. Flowable 8.0.0 matters most right now. Its release notes describe a move to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3, Jackson 3 as the default JSON library with a Jackson 2 compatibility layer, and removal of JUnit 3 and 4 support. Custom delegates that serialize JSON, custom tests and Spring configuration are the most likely to need changes. Ask for the upgrade approach in writing, including how database schema changes and regression tests will be handled.
What must our team provide before a Flowable customization project starts?
Mostly access, decisions and named people. Provide a test environment with the database and identity provider the engine will use, the process and decision models in scope, API contracts and broker topics for integrations, and owners who can settle business rules. Also provide source repository access, build and deployment pipeline access, and a contact who can approve security reviews. Missing items often delay schedules, so the written scope should list each dependency and who supplies it. Ask the partner which items are required before work begins and which can arrive during the build.
How DeployOpen delivers Flowable customization
DeployOpen scopes Flowable customization in writing before any code is written, then builds Java delegates, service tasks, event registry channels and custom REST endpoints inside your own infrastructure. Engagements are fixed-scope, with ongoing support available as a retainer.
How we scope
- We list each custom delegate, expression, service task and event channel the written scope covers, with its owning process.
- We confirm which Flowable engines are in use (BPMN, CMMN, DMN or the event registry) and which ones the customization touches.
- We record the target Flowable version and Java and Spring baselines, so the customization is designed against the release you will run.
How we build
- We implement delegates and service tasks as Java code with unit tests, and wire them into process models through explicit, reviewed expressions.
- We build event registry channels for your broker, such as Kafka, and test message ordering, retries and failure handling against a staging environment.
- We keep custom REST endpoints and any task UI under version control, with access rules that match your identity model before go-live.
How we hand over
- We deliver source code, build pipelines, deployment steps and a written inventory of every custom extension and its configuration.
- We document how each delegate, listener and channel behaves, including error paths, timeouts and what happens to in-flight instances.
- We run a handover session with your engineers and walk through a regression test of the process models before the scope closes.
How we support
- Post-delivery support is available as a retainer, covering fixes to custom code, dependency updates and reviews before each Flowable upgrade.
- Ask in the quote which upgrade and regression testing is included in the retainer and which is billed as separate work.
- Ask who on the DeployOpen side owns response, how issues are escalated and what your team must provide to reproduce a problem.
