Flowable 6 UI apps: replacement plan

Why the Flowable 6 UI apps need a replacement plan

If your Flowable 6 application depends on the bundled Modeler, Task and Admin apps, the engines themselves are not going away, but the front ends must be chosen, built or retired before or during your move to Flowable 7 or 8. Version 7 removed the UI applications, along with the form and content engines, as stated in the Flowable 7.0.0 release notes. Any screen your users or administrators rely on today will not arrive with the upgrade, so it needs an owner and a plan.

The release notes describe version 7 as focused on the BPMN, CMMN, DMN and event registry engines and their REST APIs, and later versions continue that focus. The practical consequence is that the Java APIs and REST endpoints are the stable contract you build against, while the screens that once sat on top of them are your responsibility. This page covers four areas: how process and case models are authored after the Modeler is gone, how task lists are built on the REST API, how admin views are provided, and how form definitions that lived in the removed form engine are moved or replaced.

Start by inventorying which of the three apps your organization actually uses, who uses them, and which models, forms and tasks depend on them. Confirm with your Flowable account team or the release notes whether any part of the removed functionality is covered by another Flowable product before you assume it is. The decisions you make about modeling tools, task front ends and form storage will shape the size of the migration, so they belong in the plan before the engine upgrade starts.

What changes when the Flowable 6 UI apps are removed

This table compares each baseline and scope change that affects a team leaving the Flowable 6 Modeler, Task and Admin apps, with the impact on existing work and the action each one requires. Read it as a checklist: the UI removal is the change you must replace, while the Java, Spring and Jakarta moves determine what the replacement can run on.

Change	Impact	Action needed
UI applications removed in version 7	The Modeler, Task and Admin apps no longer ship with the engine, so model editing, task work and admin views must come from elsewhere.	Choose a modeling option and build task lists and admin views on the REST API before the upgrade cutover.
Form and content engines removed in version 7	Form definitions that the form engine interpreted no longer run as they did in version 6.	Inventory existing form definitions and decide whether to rebuild them as front-end forms or move the data entry logic into your application.
Mule integration removed in version 7	Any flows that depended on the Mule integration have no built-in path in version 7.	Identify each Mule-based flow and replace it with a supported integration point defined in the Flowable docs.
Async history removed in version 7	History is no longer written asynchronously, which changes how admin and reporting views read recent activity.	Measure history write load and confirm which admin and audit views need data in the new timing model.
Focus on BPMN, CMMN, DMN and event registry engines and REST APIs	The supported surface is the engines and their REST APIs, so custom UI work must call those APIs directly.	Map each UI feature you use to a REST endpoint or to your own application, and confirm the endpoint exists in your target version.
Java 17, Spring Boot 3 and Jakarta EE baseline in version 7	Your application server, Spring version and javax imports must move to Jakarta-compatible versions before the new front end can run.	Confirm JDK, Spring Boot and servlet container versions in the Flowable 7.0.0 release notes and plan the namespace change.
Spring Framework 7 and Spring Boot 4 baseline with Jackson 3 in version 8	Version 8 drops Spring Boot 3 support and makes Jackson 3 the default JSON library, which affects REST clients and any JSON-based front end.	Test REST responses and JSON handling against Jackson 3, and sequence any front-end rework with the engine upgrade in the Flowable 8.0.0 release notes.

Which modeling option fits your team

The free Flowable Cloud Design application models BPMN, CMMN, DMN and other model types at no cost, but every person who edits models must register a Flowable account first. That makes account administration part of your model governance, and the hosted tool becomes a place where model content is stored outside your infrastructure.

Account ownership: Decide who holds accounts, who approves new ones, and how access is removed when people change roles or leave.
Hosting location: Confirm where the application and stored models are hosted and which jurisdiction applies, because data residency rules may cover model content that names customers, products or internal steps.
Export fidelity: Export a sample BPMN, CMMN and DMN file and reload it in your engine to confirm that ids, extension elements and namespaces survive the round trip.
Terms of use: Read the terms for the free tier, including limits on users, models and commercial use, and keep a copy with your project records.
Git versioning: Commit exported XML with the release it belongs to, so the Git history, not the hosted tool, is the record of which model version ran.

Confirm hosting, export behavior and terms in writing before any team builds production models in the application.

Moving form definitions out of the removed form engine

Form definitions built for the Flowable 6 form engine have no engine to run them in version 7, so each one needs a new home in your application front end or in a separate form layer before the upgrade goes live. Start with an inventory. List every form key referenced by a user task, start event or form-driven page, and for each one record the fields, field types, default values, required flags, dropdown sources and any expressions that compute values. Then check which Flowable 6 features each form relied on, such as form properties that populated process variables directly, so you know what behavior must be reproduced. Confirm the exact form-definition format your front end will consume with your own engineers before you convert anything, because the target format is a design decision for your team and not something this page can specify.

Map every form field to a process variable explicitly. Give each field a variable name, a Java or JSON type, and an owner who decides when the variable is written. Watch for fields whose names differ from the variable names the BPMN model or delegates read, and for variables that were set as a side effect of form submission and are no longer set once the form moves out. Task definitions that reference a form key need a replacement lookup, so decide whether the front end resolves the key itself or whether a service maps task definition keys to screens. Keep that mapping in version control next to the process deployment so a model change and its screen change ship together.

Split validation between the browser and the server. Use the browser for format checks and immediate feedback, but never treat those checks as the control. Put rules that decide whether a process may advance, such as limits, cross-field dependencies and checks against stored data, in a service layer or in the engine through expressions and delegates, since the REST API accepts requests that bypass any screen. Test both layers with invalid payloads sent directly to the REST API. Record which validation sits where, because auditors and security reviewers will ask how a rejected submission is enforced.

What a Flowable 7 or 8 front end needs to cover

Flowable 7 and 8 ship the engines and their REST APIs, not the Modeler, Task or Admin applications. The cards below list the components a replacement front end has to provide, each mapped to the Flowable interface it depends on. Scope them together so the task, start form, instance and admin views share one identity and error-handling model.

Task inbox with claim and complete

This view lists tasks assigned to the signed-in user or their groups, and lets a user claim a task or complete it with form data. It depends on the Flowable REST API for task queries, claim and complete calls. Check that the task query returns only what each user is authorized to see, because the engine leaves authorization checks to your application. Confirm the exact task endpoints and parameters against the REST documentation for your target version before you design the screens. Authorization checks belong in your application layer.

Process start forms

Start forms collect the variables a process needs before its first task runs. Because the Flowable 6 form engine was removed in version 7, these forms have to be rebuilt in your front end or in a separate form service, and their field definitions moved over by hand. Validate each field against the process variable types and expression usage in your models. Confirm how your chosen form tool stores and versions definitions before you migrate them.

Process and case instance views

Instance views show where a running process or case sits, which variables it holds, and what history it has produced. They depend on the REST API for runtime and history queries across BPMN processes and CMMN cases. Plan for large instance counts by paging queries and by agreeing which history fields the views need. Confirm which history data your engine configuration keeps before promising users a full timeline.

Deployment, failed job and definition admin

Admin views cover deployed process and case definitions, deployment history, and failed jobs with their retry actions. They depend on the REST API for deployments, definitions and jobs, and they replace the admin screens that version 7 removed. Give operators a way to retry or inspect failed jobs without direct database access. Check which job and deployment operations your target version exposes before you scope this card.

Identity and role mapping

The front end must map your directory groups and roles onto the users and groups that task assignment and admin access rely on. Flowable's identity management can be replaced by implementing its identity service interface, and an LDAP reference implementation is provided. Decide where this mapping lives so that the task inbox, start forms and admin views apply the same rules. Confirm the identity service approach and its behavior in your target version before you build against it.

Monitoring through the actuator endpoint

The Spring Boot starters expose an actuator endpoint at /actuator/flowable that reports on running processes, which gives operators a view that does not depend on the front end. Use it to build dashboards and alerts alongside your admin views rather than rebuilding the same data. Restrict access to the endpoint, since it describes running work. Confirm which metrics the endpoint returns in your version and how it is secured in your Spring Boot configuration.

Building task lists and admin views on the REST API

The first decision is where the API lives. Your team can run the Flowable REST application as a separate service and have the front end call it over HTTP, or embed the engines in your own Spring application and expose endpoints that your front end calls. Both routes give you task queries, process instance views and history lookups, but the second route also lets you shape responses for your screens and keep the engine's internal model away from the browser. Whichever you pick, confirm each endpoint, query parameter and filter option against the exact engine version you target, because the REST surface changes between major releases and some Flowable 6 calls have no direct equivalent in version 7 or 8. The Flowable 7.0.0 release notes describe which components moved to the REST API as the supported surface, so start there when mapping old screens to new calls.

Identity is the part most teams underestimate. The Flowable docs say identity management can be replaced by overriding IdmIdentityServiceImpl or by implementing the IdmIdentityService interface, and an LDAP implementation is provided as a reference. Your task list, assignee pickers and admin views must read users and groups from the same source the engine uses for candidate groups and assignees. If the front end resolves names from a different directory, or caches group memberships separately, users will see tasks they cannot claim or miss tasks they should see. Agree on one identity source, decide how group changes propagate, and test a user whose group membership changes while a task is open.

Preparation before the first front-end build

Before anyone writes a line of front-end code, the team needs a recoverable baseline, a clear list of what the Flowable 6 UI applications did for users, a realistic place to test changes, and named owners for each replacement. The four cards below are the outputs that make the later build decisions safe and reviewable.

Full engine database and model backup

Take a full backup of the engine database and every deployed process, case and decision model, with a record of which definition versions are live. Keep the backup restorable and tested, because the replacement front end will read the same runtime data and any later schema step needs a known rollback point. Ask the database owner to confirm the restore procedure works on a separate instance. Sign-off: the platform owner and the DBA, with the backup test result attached.

Inventory of UI-dependent customizations

List every custom form, task list link, admin bookmark, saved filter and script that depended on the Flowable 6 UI applications. For each item, record the user group, the data it reads or writes, and whether it calls the engine directly or through a browser page. This list defines the scope of the replacement, since anything missing from it will break silently after cutover. Sign-off: the business process owner for each affected workflow, confirmed with the application lead.

Production-like test environment

Build a test environment that matches production in engine version, database type, data volume and identity source, including the directory or identity service that supplies users and groups to task assignment. Without realistic identities and volumes, task visibility, candidate groups and admin queries will behave differently than they do in production. Confirm with the security team that test data copied from production is masked or handled under your data protection rules. Sign-off: the QA lead and the security owner.

Decision record with named owners

Write a decision record that names the chosen option for each replacement component: modeling, task lists, admin views and form definitions. For each component, state the owner, the review date and the conditions that would reopen the decision. This record prevents the front end from being built by default around whichever tool a developer finds first. Sign-off: the CTO or head of platform engineering, with the business owners named in the record.

Sequence for replacing the UI apps during the upgrade

This sequence moves task handling, model editing and administration off the Flowable 6 UI applications and onto a front end built on the REST API, with each step gated by a check and a point where the old UI can still be used. It is designed so the engine upgrade and the front-end change do not have to succeed in the same cutover.

Confirm the target engine version and baseline
Pick the target Flowable version and check its Java, Spring and Jakarta baseline against your runtime, build tooling and test suites before any UI work starts. The Flowable 7.0.0 release notes say version 7 removed the UI applications, the form and content engines, Mule integration and async history, so every feature your users rely on in the old apps needs an owner in the new design. Version 8.0.0 requires Spring Boot 4 and has no Spring Boot 3 compatibility, so confirm which Spring Boot line your application will run. Done when the team signs off a written baseline and a list of removed features, each marked as replaced, retired or accepted as lost.
Freeze model changes and inventory the UI
Stop edits to BPMN, CMMN and DMN models, forms and admin configuration for the duration of the replacement, and record the freeze date in the change log. Inventory what the Modeler, Task and Admin apps did for your organization, including who edits models, which task lists people use, which filters and reports admins run, and which form definitions drive user input. Done when the inventory is reviewed by process owners and each item has a named replacement or an approved retirement.
Export and version all models and form definitions
Export every deployed process, case and decision definition, along with the form definitions the old UI stored, and commit them to version control with their deployment identifiers. Keep a copy of the old database schema and a restorable backup before the export, since the UI apps may have stored data the engine does not. Confirm that a clean engine can redeploy the exported models and that form definitions open in a viewer you control. Done when a test environment reproduces the deployed definitions from the repository with no manual edits.
Build the replacement front end against a test environment
Build the task list, model viewing and admin views on the Flowable REST API, running against the test environment created in the previous step. Keep the front end's dependencies on the engine behind the REST contract, so later engine changes affect fewer screens. Test each query and task action, including claims, completions and variable updates, against the exact engine version you plan to run. Done when every function on the inventory has a passing test against the test environment and the team has documented the REST calls the front end depends on.
Run parallel task handling on a limited set of processes
Route tasks from a small, agreed set of low-risk process definitions to the new front end while the old UI remains available for all other work. Compare outcomes by checking task assignment, due dates, variables and completion results in the engine history for the same process types handled through each path. Keep the old UI reachable and its access unchanged so users can fall back for any process at any time. Done when the new task list has completed a full run of representative tasks for every process in the pilot set, with no mismatched variables or missing assignments, and the rollback path has been exercised once.
Cut over the front end and confirm user access
Switch the default entry points for task handling and administration to the new front end, and update links, bookmarks and documentation for users and administrators. Confirm that identity and permission mapping works for each role, since the engine leaves authorization checks to your application. Keep the old UI in read-only or standby mode for an agreed period you set in advance, and record the rollback steps in the runbook. Done when support tickets and task completion counts show normal activity on the new front end and the rollback steps have been confirmed by the operations team.
Retire the old UI and archive its data
After the standby period ends without an unresolved rollback need, remove the Flowable 6 UI applications and their access paths from the environment. Archive the exported models, form definitions, UI configuration and final backup under your retention policy, so you can answer questions about past forms and approvals. Update the architecture record to show that the front end depends only on the REST API. Done when the old applications are no longer reachable, the archive has been verified by restoring a sample, and the decommissioning is recorded as complete.

What makes the front-end replacement take longer

This table lists the drivers that change how long it takes to replace the Flowable 6 Modeler, Task and Admin apps, and what each one means for planning. Use it to inventory your current estate before choosing a modeling option or estimating the build. The main takeaway is that the count of forms, UI-only behavior and identity mappings usually matters more than the number of applications being replaced.

Driver	Why it matters	What to check
Forms and admin views in use	Each form definition or admin screen must be rebuilt, re-tested and re-approved. Forms that were never used can be dropped instead of rebuilt.	Export the list of form definitions and admin screens, then mark which ones users open in a typical month and which ones only exist for past projects.
Identity sources and role mappings	Version 7 no longer ships the UI apps, so task visibility and admin rights must be enforced by your own application. Each identity source and group-to-role rule adds design and test work.	List every identity provider, directory or LDAP source, and the groups that map to Flowable candidate groups, owners and admin roles.
Models that depend on UI-only behavior	Some process or case models rely on form rendering, the task inbox or admin actions that have no direct engine equivalent. These need a replacement before the model can run unchanged.	Search your BPMN and CMMN models for form keys, form references and task actions, and note which ones only work when a person uses the old UI.
Depth of Flowable 6 customization	Custom skins, custom task list logic, modified admin pages and patched UI code are not carried over. The more code sits inside the old applications, the more is rebuilt from scratch.	Compare your deployed war or customized UI modules with the stock applications, and record each change along with its owner and reason.
Data volume in active instances and history	Large numbers of running tasks and history records affect how the new task lists and admin views query data. Paging, filters and indexes need testing against realistic volumes.	Count running process and case instances, open tasks and history rows per table, and confirm which queries the new screens will run most often.
Plans to adopt a commercial modeler	A commercial modeler can change the form, model and deployment workflow. Choosing it early avoids rebuilding forms for a second time, but it adds licensing and onboarding steps.	Decide whether the team will use the free Flowable Cloud Design application, a commercial product or a self-built editor, and ask the vendor which model and form formats it reads and writes.

Questions teams ask before replacing the Flowable 6 UI apps

Can our own team replace the Flowable 6 Modeler, Task and Admin apps without a partner?

Yes, if your team has Java and Spring engineers who already run Flowable and a front-end developer who can work against the REST API. Version 7 removed the UI applications, so you are building replacements, not configuring a product. The main questions are whether you have capacity for the build, the testing and the ongoing maintenance of a front end you now own. Many teams split the work: they keep modeling in a tool they already trust and build task lists and admin views internally, then bring in outside help for the parts they lack experience with.

What drives the cost of replacing the Flowable 6 UI apps?

The cost follows the scope written down before work starts. The main drivers are how many process and case models need a modeling workflow, how many task list and admin views you need, how much of your form logic moves to new front ends, and how many user roles and permission rules must be enforced in the new screens. Costs are one-time for the build and recurring for upkeep, such as dependency updates and fixes when the engine or the Spring baseline changes. Ask any quote to split build effort, testing, identity integration and ongoing support, and to state which parts are fixed and which depend on discovery.

How long does the replacement take, and what sets that range?

No duration is given here because the range depends on your environment. The biggest factors are the number of screens, the complexity of the forms and their validation, how tightly the task lists must reflect your existing workflows, the identity provider you connect to, and how many people must review and sign off each view. Teams with a clear inventory of what the Flowable 6 apps actually did usually plan more accurately. Ask for a timeline tied to named milestones such as an inventory, a prototype of the task list, a permissions review and a user acceptance test.

What do our engineers and product owners need to provide?

Your engineers need access to the Flowable REST API in a test environment, the process and case definitions, the existing form definitions and a working identity setup. Product owners need to decide which tasks users should see, who may act on them, what admins must be able to change and which screens are still needed at all. Plan time for both groups to review prototypes, because most rework comes from unclear task visibility rules rather than from the code. Ask the provider to name these inputs in the written scope so gaps are visible early.

Can we use the free Flowable Cloud Design application with our data policies?

Possibly, but confirm it before you rely on it. Flowable offers a free Cloud Design application for modeling BPMN, CMMN, DMN and other model types, and it requires registering a Flowable account. Check with your security and legal teams whether that account, the hosting location of the tool and the handling of model content fit your data classification and vendor rules. If the answer is no, the alternative is a modeling approach you run in your own environment, which needs its own selection, deployment and support. Confirm the terms directly with Flowable and document the decision.

Can we keep the Flowable 6 UI apps running on a Flowable 7 or 8 engine?

No. Flowable 7.0.0 removed the UI applications, so they are not part of the version 7 line, and Flowable 8 builds on that same set of engines and REST APIs. Keeping the old apps alive would mean hosting a Flowable 6 stack alongside the newer engine, which pushes you back toward the Java and Spring baseline you were trying to leave. The practical path is to decide which screens you need, build replacements against the REST API and retire the old apps once users and admins have moved over.

What should we ask for in a quote for this work?

Ask for a written scope listing each model type, screen and admin function, with its acceptance criteria. Request the assumptions behind effort, the named roles from both sides, the environments used for testing, and the handling of identity, roles and form data. Ask which items are one-time and which recur, such as support or upgrade work tied to the Flowable 7 or 8 line. Also ask how changes to scope are priced and approved. A quote that cannot be traced back to these items is hard to compare with an internal estimate.

How DeployOpen scopes and delivers the front-end replacement

DeployOpen plans, builds, documents and supports self-hosted Flowable deployments inside your own infrastructure, so the replacement for the Flowable 6 Modeler, Task and Admin apps runs where your processes already run. Engagements are fixed-scope, with the front-end work defined in writing before any build starts.

How we scope

Inventory every Modeler, Task and Admin feature your users rely on, and decide which ones move to a new tool and which are retired.
Record which model types, form definitions and user roles the new front end must support, including who edits models and who approves them.
Put the chosen modeling option, API calls, identity source and deliverables into a written scope before work starts, since engagements are fixed-scope.

How we build

Build task list and admin views against the Flowable REST API, with the authorization checks your application enforces on each request.
Convert form definitions into the form format your chosen front end reads, and test each converted form against real process variables.
Run regression tests on task completion, claiming, delegation and variable updates in a non-production environment that mirrors your database.

How we hand over

Document the deployment, configuration, API contracts and known gaps so your platform team can run the front end without us.
Hand over source code, build pipeline steps and test suites in your own repositories, under your control.
Walk your operations and support staff through the admin views, the task workflows and the runbook for common failures.

How we support

Support the front end after go-live through a retainer that covers upgrades, fixes and security patches as Flowable versions change.
Review the front end when you plan a Flowable 7 or 8 move, including changes to REST responses and the Spring and Jackson baseline.
Keep the scope, documentation and tests current so each later change starts from a known state, with the retainer terms confirmed in writing.

Replacing the Flowable 6 Modeler, Task and Admin apps