Building a Flowable task list UI on the REST API when the task app is gone
If your team used the Flowable 6 task app to work through human tasks, or needs a work queue for people to pick up and complete process steps, the open-source 7 and 8 line will not give you that screen. The 7.0.0 release notes say version 7 removed the UI applications, along with the form and content engines, Mule integration and async history. Your replacement front end is therefore something you build or buy, and the supported way to build it is the Flowable REST API. The API is served by the Flowable REST application, which exposes the BPMN, CMMN, DMN and event registry engines over HTTP. The Flowable getting started guide describes HTTP access as one of the ways to use the engines, alongside embedding them as a JAR in Java SE, servlet container, Spring or Java EE applications.
Build this yourself when your team has frontend and Java capacity, the task screens follow your own roles and workflow, and you want the front end to live in your own release process. Buying a commercial Flowable product is the other route. Flowable's commercial products, including Flowable Work, are built on the same engines and add low-code modeling and monitoring, according to the Flowable open source page. Open-source users get a community forum, with professional services and partners offered separately. Before choosing, confirm with the vendor which task-list features the commercial product covers, since a custom build will need its own forms, filtering and access logic.
Before scoping the build, confirm three things in your own environment: which Flowable version you will run, since the REST API and its endpoints change between major releases, which identity source the API will authenticate against, and whether your team can own the API client code for the life of the application. Ask the engineers who will maintain the screen to read the version's REST documentation and confirm the exact endpoints for querying tasks by candidate group, claiming, completing and reading variables. A task list that works on a test deployment can still fail on a version upgrade, so treat the API contract as a dependency you track and test.
Which integration pattern fits each team
This table compares three ways to put a task list in front of users: a single-page app calling the Flowable REST API directly, a backend-for-frontend that holds credentials and maps groups to users, and a server-rendered app using the Java API inside the same application. Read each row to see who holds the credentials, how candidate groups reach the user, and what the choice asks your team to maintain over time.
| Pattern | Who holds credentials | How candidate groups are resolved | Maintenance cost |
|---|---|---|---|
| Single-page app calling REST directly | The browser holds a token issued by your identity provider, and Flowable checks it on each call | The token must carry group claims that match the Flowable group names, or the app depends on a mapping the engine does not supply | Low server code, but group claim mapping and token lifetime rules must be kept in step with Flowable and the identity provider |
| Backend-for-frontend | A server component holds the Flowable service credentials and the browser holds only a session | The BFF looks up the user's groups in your identity source and sets candidate group filters on each task query | Moderate: the BFF is an extra service to build, secure, deploy and upgrade, but it keeps the mapping in one place |
| Server-rendered app using the Java API | The application's own server holds the engine service beans and no separate Flowable credentials are exposed to browsers | Candidate groups come from the application's identity service, such as a custom IdmIdentityService implementation | Highest coupling: the UI shares a release cycle with the engine, so Flowable upgrades touch the UI code |
| Fit for teams with a separate front-end group | Usually the BFF, so front-end developers never receive service credentials | Mapping logic lives in one server component that both front-end and back-end teams can review | Ask who owns the BFF after launch, since it becomes a service with its own on-call and patching needs |
| Fit for teams already running Flowable in Java | Usually the server-rendered app, because the engine is already on the classpath | Reuses the identity service the process already uses for assignments | Lowest integration effort, but confirm that your upgrade plan covers the UI as well as the engine |
| Fit for a small team with an existing SSO | Usually the single-page app, if the identity provider can issue tokens the REST API accepts | Depends on group claims; confirm how your provider emits them and how Flowable reads them | Fewer moving parts, though token claim changes can break task lists without a code change in the UI |
| Audit and evidence trail | Ask which component performs the claim and complete calls, since that determines where user actions are logged | Record which mapping source produced each candidate group filter | Each pattern needs logging of user, task and action, and this cost grows with the number of services involved |
How API authentication and identity mapping change the build
Teams that run Flowable with the users and groups the engine ships with can build the task list against the REST API using HTTP basic authentication or a token issued by a gateway in front of it. The engine stores users, groups and memberships in its own tables, so the same identifiers used in a BPMN candidateGroups attribute also appear in the identity data the API returns. This setup is quick to prototype, but the default accounts are a known risk, so they must be replaced or disabled before any shared environment is opened.
- Default accounts: Remove or change the sample users before the API is reachable from a browser or another network segment.
- Group names: Match candidate group IDs in your models to the group IDs the engine stores, character for character.
- Password handling: Confirm how the REST application stores and checks credentials for your version, and whether basic authentication runs only over TLS.
- Authorization gap: The engine returns tasks for a user's groups, but it does not stop your front end from calling endpoints for tasks outside that user's view.
Before go-live, confirm with the Flowable security documentation for your version which default accounts exist and how to disable them.
Teams with an existing directory, such as LDAP or Active Directory, usually replace the engine's identity handling so that users and groups come from the source of truth. Flowable documents this route: you override IdmIdentityServiceImpl or implement the IdmIdentityService interface, and an LDAP identity service is provided as a reference. The task list then queries the same identity service the engine uses, so group membership shown in the UI and group membership used for task candidacy come from one place.
- Reference implementation: Start from the documented LDAP reference and adjust attribute mapping, search bases and group filters to your directory.
- Nested groups: Decide whether nested or indirect group membership must be expanded, because the engine checks the groups it is given, not the directory structure behind them.
- Group naming: Map directory groups to the exact candidate group identifiers used in BPMN and CMMN models, and keep that mapping in version control.
- Caching and latency: Test how directory lookups behave under load, since task queries may call the identity service repeatedly.
- Changes in membership: Define when a user's group changes take effect, so a user removed from a group stops seeing its tasks.
Confirm the identity service interface and override approach against the Flowable version you run, since the supported extension points change between major releases.
Teams that place an external identity provider in front of the task API usually authenticate users with OpenID Connect or SAML at a gateway or in the front end, then pass a verified token to the Flowable REST application. The provider proves who the user is, but it does not know which Flowable groups that user belongs to. The build therefore needs a mapping step that reads claims from the token, translates them into Flowable group identifiers, and rejects requests that carry no mapped group. Flowable's own user store can still hold the users and groups the engine needs for candidate matching.
- Token validation: Validate signature, issuer, audience and expiry at the gateway or the API layer before any Flowable call.
- Claim-to-group mapping: Define which claims become candidate groups, and keep the mapping under review as roles change.
- Synchronization: Decide whether Flowable users and groups are provisioned ahead of time or created on first login, and who owns that process.
- Service accounts: Keep backend calls from the front end under a separate identity with only the permissions it needs.
- Logout and expiry: Confirm that tokens expire quickly enough that a removed user loses access within your policy window.
Check with your identity provider's documentation which claims it can emit and whether group membership arrives in the token or must be fetched separately.
Whichever identity model you choose, the Flowable engine does not decide which user may see or act on a given task unless your application enforces that rule. A query such as tasks by candidate group returns what the engine matches, so the front end or a proxy must confirm that the authenticated user belongs to the group before claiming or completing a task. Identity mapping is the piece that makes this work: the groups produced from a user's login must be the same identifiers that appear in BPMN candidate groups, or users will see empty lists or the wrong tasks.
- Server-side checks: Verify the caller's groups on every claim, complete and variable update, not only on list views.
- Shared identifiers: Use one naming scheme for groups across models, directory and token claims, and test it with a sample process.
- Assignee versus candidate: Confirm that claiming a task moves it to the user as assignee and that only the assignee or an authorized user can complete it.
- History access: Apply the same group checks to history queries, which can expose data about tasks the user never handled.
- Negative tests: Include cases where a user from another group attempts each action and confirm it fails.
Before release, ask the Flowable security documentation for your version which authorization checks the engine leaves to your application, and document each one.
Setting up the task list build step by step
This sequence takes a team from a confirmed Flowable version to a working task list front end that queries, claims and completes tasks through the REST API, with a check at each step so problems surface before the UI is built on top of them.
Confirm the Flowable version and Spring Boot baseline
Before any code is written, the platform lead records the Flowable version, the Java runtime and the Spring Boot baseline the project will use. Flowable 8.0.0 moved to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3, and Jackson 3 is the default JSON library, so the front end's HTTP client and any JSON mapping must match what the REST application returns. Confirm the baseline against the 8.0.0 release notes and your own dependency inventory. The step is done when the versions are written down and agreed by the team that owns the process application.
Deploy the Flowable REST application or starter
The back-end team deploys the Flowable REST application or adds the REST starter to the existing Spring Boot service, depending on whether the engines run in their own process or inside the application. Both options expose the same REST resources, so the choice follows your deployment model. The check is a simple authenticated call to the tasks endpoint returning an empty or valid JSON response rather than an error or a login page. Confirm the exact endpoint paths against the REST documentation for your version, since the task list depends on them.
Configure the database type
Select the database the engines will use and set the connection properties in the configuration. Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server. If you choose MySQL, confirm the server version, because versions below 5.6.4 lack millisecond precision, which affects task and history timestamps shown in the UI. The check is that the engine starts, creates or validates its schema, and the database shows the expected Flowable tables. Do this before loading a process so that task records are stored in the database you will operate.
Load a sample process with candidate groups
Deploy a small BPMN process whose user tasks set candidateGroups, for example two lanes or two groups such as underwriters and reviewers. Keep the model minimal so that any failure points to the task assignment and not to the business logic. Start a few instances through the REST API. The check is that the tasks appear in the runtime task query with the expected candidate group assignment, and that tasks for one group do not appear for users who belong only to the other.
Wire authentication for the REST calls
Choose how the front end authenticates to the REST API and configure the back end to accept it. Your identity provider or gateway should pass a verified user identity and group membership, and the Flowable identity service must resolve those groups so that candidate group queries match. Flowable allows identity management to be replaced by implementing its identity service interface, which is where your directory integration usually sits. The check is that a request with a valid token returns tasks for the right user and a request without credentials is rejected. Confirm the default accounts are disabled or changed before this step is signed off.
Build the query, claim and complete calls
The front-end team implements three operations against the REST API: a task query filtered by candidate group or assignee, a claim call that assigns the task to the current user, and a complete call that submits the task variables and advances the process. Keep the claim as an explicit step, so the UI can show ownership and prevent two users from completing the same work. The check is end to end: claim a task as one user, confirm it disappears from the other group's queue and from other users' lists, complete it, and confirm the next task appears in the correct queue.
Verify with a test user for each group
Create one test user per candidate group, plus a user in no group, and run the full flow with each account. Confirm that each user sees only the tasks they are entitled to, that a claimed task is removed from other queues, that completing a task with variables updates the process, and that history views show the completed steps. Record the results with the process version and database used. The step is complete when every user's expected and actual task lists match, and the test script or checklist is kept with the code so it can be rerun after upgrades.
Security checks for the task API and the front end
A task list front end is a thin layer over engine calls, so the security work sits in what the API lets a caller see and change. The cards below cover the checks your application must add on top of the engine, from authentication on every call to logging claim and complete actions. Confirm each item against your own deployment before the first user signs in.
Authenticate every REST call
Every request to the Flowable REST endpoints should carry a verified identity, including calls the front end makes on behalf of a logged-in user. Do not leave any task, variable or history route reachable without credentials, even on an internal network. Put the check in a gateway or servlet filter in front of the REST application, and test it with requests that have no token, an expired token and a token from another application. Confirm which authentication options your Flowable version supports for the REST application before you design the login flow.
Check task ownership in your code
The engine does not decide whether a signed-in user may see or act on a given task, so your application must. Before a claim, complete or variable update, confirm the task is assigned to the user or is a candidate task for a group that user belongs to. Compare the task's assignee and candidate groups with the identity your gateway resolved, not with a value sent from the browser. Illustrative case: a user who passes another user's task ID in a complete request should receive a refusal, not a completed task.
Remove default accounts from production
Development setups often ship with sample users and passwords that let anyone sign in to the engine's own identity store. Before production, confirm which default accounts exist in your Flowable version, remove or disable them, and make sure your front end does not use them as a service identity. The Flowable security area covers default accounts and password storage in detail, so use it as the checklist for this step. Also confirm that the service account your back end uses has only the permissions the task API needs.
Filter personal data in task responses
Task and variable responses often carry personal data such as names, dates of birth or account numbers, and the default JSON for a task can include every process variable. Decide which variables each group may read, then filter responses on the server rather than relying on the browser to hide fields. Pay attention to variables set by earlier steps in the process, since a reviewer task may expose data the original requester entered. Confirm the rules with your privacy and data protection owner before the list view goes live.
Log claim and complete actions
Record who claimed or completed each task, when it happened and which API call made the change, in a store your security team can query. Engine history records task events, but your application log should also capture the authenticated user, the requesting IP address and any refusal from the ownership check. Keep these entries separate from business data and protect them from edits by the application's own users. Ask your compliance lead which retention period applies before setting log rotation.
Review the front end's trust boundary
A browser-based task list holds tokens and renders data from the API, so it adds its own risks. Keep tokens in a form the script cannot read where your identity setup allows, set a strict content security policy, and escape task names and variable values before rendering them. Review which origins may call the API, and avoid exposing the engine's REST endpoints directly to the internet. Treat each front-end release as a change that needs the same review as a back-end change.
Questions teams ask before building a Flowable task list
What does it cost to build a task list UI on the Flowable REST API?
The cost is mostly the engineering effort to build and test the front end, plus the effort to design access rules and the API integration. The main cost drivers are the number of task queues, how complex the forms are, how identity is integrated, and how much audit and history detail users need to see. Ongoing costs are the people who maintain the UI through Flowable upgrades and changes to process models. When you request a quote, ask for the effort split between front-end build, API and authentication work, testing, and handover, and ask which items are one-time and which recur. Any fixed-scope quote should list the queues, forms and history views included, because each one adds build and test work.
What makes a Flowable task list take longer to build?
Duration depends on scope, so the useful question is which factors extend it. The biggest factors are how many candidate groups and queues the list must serve, whether task forms are simple or rendered from complex form definitions, how users are authenticated and mapped to groups, and whether the UI needs variable-level history or audit trails. Each adds design decisions, API calls to verify, and test cases. Teams with stable identity data and a small set of queues usually finish faster than teams that must reconcile several directories. Ask any partner to break the schedule down by these drivers so you can see which ones your environment triggers.
Who on our side needs to be involved in the build?
Three groups need to be involved from the start. Identity owners decide how users, roles and candidate groups are defined and how the front end receives them, and they confirm which claims or directory groups the API must trust. Process owners define which tasks belong in each queue, what the form fields mean, and who may claim or complete a task. A test group made of real users from the affected teams should exercise claim, complete and reassign flows before release. Without these people available for review, the most common rework is changing group rules after the UI is built. Confirm their time commitments before the scope is signed.
Can our own team build a Flowable task list UI without a partner?
Yes, if your team has front-end and Java or REST integration experience and can own the authentication design. The Flowable REST API exposes the task operations you need, and the open-source engines are licensed under Apache 2.0, so no license fee applies to building your own front end. The risks are in the details: securing the API, handling candidate groups correctly, and testing claim and complete races. Teams that build internally often underestimate the security review and the testing effort. A partner can take over a fixed-scope piece, such as the authentication and authorization design or the test plan, while your team keeps the day-to-day build.
What security checks should a custom Flowable task list pass?
Start by confirming that every task action is authorized by the application, not only hidden in the interface. Flowable leaves many authorization checks to your application, so the API layer must confirm that the signed-in user may view, claim or complete a specific task. Review how the front end obtains tokens, how sessions expire, and whether default engine accounts are disabled. Also check how variables that contain sensitive data are displayed and logged. Your security team should review these controls against your own policy before release, and any external audit should be planned separately.
What does a commercial Flowable product change for a task list?
The open-source engines and the REST API are the same foundation that Flowable's commercial products build on. According to Flowable's open source page, the commercial products, including Flowable Work, Engage, Orchestrate and Design, add low-code modeling, visual debugging, security controls, monitoring and governance. If a commercial product already provides the task inbox, forms and access controls you need, building your own UI may be unnecessary. Open-source users receive a community forum, while professional services and partners are offered separately. Compare license terms, support scope and the features you would otherwise build before choosing, and ask the vendor which parts of the task UI are included.
What should we ask for in a written scope for this work?
Ask for a list of task queues with their candidate groups, the forms and variables each queue displays, the actions each role may perform, and the history views included. Request the authentication design, the API endpoints the UI will call, and the test cases for claim, complete, release and reassign. Confirm which Flowable version and REST application deployment the UI targets, and how the front end will be deployed and maintained after handover. A clear written scope lets you compare quotes on the same basis and prevents later disputes about what was included.
Official Flowable sources for the task API build
Before you write any client code against the task endpoints, read the official Flowable material for the version you plan to run. Start with the Flowable open source page for the scope of the open-source engines and what the community edition includes, then the Flowable getting started guide to confirm how the Flowable REST application is deployed and reached over HTTP. Your task list front end will call that REST application, so the getting started guide tells you whether you are working with a standalone REST app or an embedded setup.
Next, read the Flowable Spring Boot docs if your back end uses Spring Boot, including the REST starter and the actuator endpoint at /actuator/flowable, which helps you confirm the service is up before you debug the UI. The Flowable advanced docs matter for two behaviors a task list will expose: how the async executor and lock expiration affect timers and jobs, and how identity management is replaced through the IdmIdentityService interface. Candidate group queries depend on that identity service, so confirm which implementation your environment uses.
Version changes are the other risk. Read the Flowable 7.0.0 release notes, which record the move to Java 17, Spring Boot 3 and Jakarta EE and the removal of the UI applications, and the Flowable 8.0.0 release notes, which record the move to Spring Boot 4 and Jackson 3 by default. Confirm the endpoint paths, request bodies and response fields against the REST reference for your exact version, since that reference is the authority for endpoints and field names.
How DeployOpen scopes and delivers a Flowable task list
DeployOpen plans, builds, tests and hands over a task list front end on the Flowable REST API inside your own infrastructure. The work starts from a written scope that names the candidate groups, task actions, variables and forms the list must handle, and it ends with documentation and a runbook your team can operate.
How we scope
- The written scope lists which candidate groups and users see which tasks, and which claim, complete and reassign actions the list must offer.
- Scope names the process and case models whose tasks appear, including the variables and forms each task type needs to display.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before the build begins.
How we build
- We build the front end against the Flowable REST application in your environment, with authentication handled by your identity provider.
- Tests cover task queries by candidate group, claim and complete calls, and error responses when a task has already been claimed.
- Variable handling, history views and form rendering are built and tested against the process definitions your team has deployed.
How we hand over
- Deliverables include source code, configuration, API usage notes and a test report, all held in a repository your team owns.
- Documentation covers how the list authenticates, which endpoints it calls and how new task types are added without code changes elsewhere.
- A handover session walks your engineers through the build, the test suite and the steps to deploy the front end into your environment.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, including updates when Flowable releases change the REST API.
- Support can cover front end changes for new task types and reviews of authentication settings after your identity setup changes.
- Ask any provider to confirm in writing which Flowable version, REST endpoints and identity provider the support covers.
