How to use this BPM requirements checklist
If you are a CIO or platform lead who must choose or build a BPM capability on open-source engines in your own infrastructure, this checklist answers one question: what must a BPM platform do, and what must it prove, before it can run your production processes? Requirements are grouped into functional, security, integration, operational and compliance categories. Each item is written as something you can verify, and each must be confirmed with a test, a document or a live demo on your own data rather than accepted from a vendor datasheet. Ask for the evidence in the same form you would expect for any control that an auditor may later sample.
Check the production license term first, before you score anything else. Flowable's engines are licensed under Apache-2.0, while the Camunda 8 source files are under the Camunda License 1.0, which permits only non-production use without a commercial license from Camunda. Camunda 7 Community Edition has reached the end of its release line, with 7.24 as the final feature release scheduled for October 14, 2025. Record the license position of each candidate in writing, including who signs for production use and for which components, so that the rest of the evaluation does not rest on a platform you cannot lawfully run.
Treat the checklist as a scoring instrument for a proof of concept, not a feature comparison. For each item, record the owner who will verify it, the test or document that proves it, and the result. Items on process versioning, running instance migration, audit history and clustering deserve the most scrutiny, because they are hardest to change after go-live. Where a candidate cannot meet an item, the decision is whether to accept a documented gap, build the missing piece, or choose another engine, and that decision should be made before a fixed-scope implementation is agreed.
Functional requirements for BPMN, case, decisions and human tasks
This table lists the functional requirements a BPM platform must meet, why each matters, and a concrete way to verify it before you commit. Use the verification column as a test plan for proofs of concept, and treat any row where the chosen version's capability is unconfirmed as an open question for the vendor or partner.
| Requirement | Why it matters | Verification method |
|---|---|---|
| BPMN process coverage | Your critical processes must run as executable BPMN, including service tasks, timers, boundary events and error handling for long-running work. | Model one named end-to-end process, such as a loan or onboarding flow, and run it through every branch, timer and error path in a test environment. |
| CMMN case management | Unstructured work such as claims or investigations needs case plans where the next step is a human decision rather than a fixed sequence. | Build one case with optional stages and milestones, then confirm the engine version you select executes CMMN, not just BPMN. |
| DMN decision tables | Eligibility, pricing and routing rules should be maintained as tables that business owners can review, outside application code. | Load a real-size rule table, run sample cases through it, and confirm the engine records which table version decided each case. |
| Human tasks and forms | Staff must claim, complete and delegate tasks with the data they need, and forms must be governed like any other application artifact. | Confirm whether forms come from the engine, a separate form layer or your own UI, then complete a task with role-restricted access and a four-eyes step. |
| Process versioning | Changing a model must not silently alter instances already running, and you need to know which version each instance follows. | Deploy version two of a model while version one has open instances, then confirm each instance keeps its original definition. |
| Running instance migration | Long-running cases such as permits or grid connections will outlive model changes, so migration of live instances is a core operational task. | Replay a version change on a copy of live instances, including instances at timers and waiting tasks, and record which ones need manual handling. |
| Audit history | Regulated reviewers ask who did what, when, under which rule version, and the history must survive engine upgrades and retention rules. | Export the complete history for one case, including tasks, decisions and variable changes, and check that it can be retained beyond the active data. |
| Engine upgrades and licensing | Engine lifecycle and license terms decide whether the platform can run in production and how long it receives security patches. | Confirm in writing the license for production use, the supported database and Java versions, and the security patch commitment for your chosen version. |
Why the production license decides the shortlist before features
The production license is a gate, so check it before comparing features. Camunda 8 source files for Zeebe, Operate and Tasklist are under the Camunda License 1.0, which limits use to non-production environments such as development, testing and evaluation. Production use requires a commercial license from Camunda. Flowable's engines for BPMN, CMMN and DMN are licensed under Apache-2.0, so a production deployment does not depend on a separate commercial agreement for the engine itself. Commercial Flowable products are an optional addition, not a prerequisite. Read the Camunda License 1.0 text yourself, then have counsel confirm how it applies to your deployment model, including any embedded use, internal tooling and the non-production copies your teams keep.
Camunda 7 end of life is a requirement input, not a footnote. The camunda/camunda-bpm-platform repository is archived, with 7.24.0 as its last tag. Camunda's final Camunda 7 feature release, 7.24, was scheduled for October 14, 2025, after which no further releases or security patches are made for the Community Edition. Enterprise Edition end of life was extended to April 9, 2030, with paid extended support available from April 2030 through April 2032. Ask any vendor or partner which Camunda 7 edition the current estate runs, whether it holds an Enterprise contract, and who will patch the engine after the community cutoff. Those answers determine whether a migration is a near-term project or an optional modernization.
Confirm the terms with the vendor in writing before the shortlist is final. Ask for the exact license that applies to each component you plan to run, including connectors, the REST layer and any web applications. Confirm which environments the license covers, what changes when you move from a pilot to production, and what Flowable's commercial products would add if you need low-code modeling, monitoring or governance. Record the answers in the requirements document so that the license, support window and migration path are assessed with the same weight as process modeling and clustering.
Integration requirements to check with existing systems
Integration is where most BPM projects stall, because a process engine is only useful once it can see users, accept work from other systems and keep time-based steps running on a cluster. The cards below name the integration points to test in a proof of concept, using the engine you shortlist.
Identity provider integration
Human tasks need candidate groups and assignees that match your directory. Flowable documents an identity management extension point: you can override its identity service or implement its interface, and an LDAP implementation is provided as a reference. Check that group membership, delegation and removed users resolve correctly against your real directory, and that tasks assigned to departed staff can be reassigned with an audit record. Confirm whether your single sign-on flow passes through the task UI you build, since the engine itself does not provide it.
REST and Java APIs for tasks
Your applications will start process instances, query tasks and complete them through the engine's Java API or REST interface. Flowable's engines ship with both, and the REST application can run as a separate service. In the proof of concept, test a full cycle: start an instance from a source system, claim and complete a task through the API, and read back variables and history. Confirm how errors and duplicate submissions are returned, since retries from calling systems are common.
System-of-record connections
Process steps usually read or update a core system such as a loan ledger, case management system or ERP. Decide whether the process calls that system directly through service tasks or through an integration layer with its own retries and logging. Verify transactional boundaries: if a service call succeeds but the engine fails to record completion, the step must not run twice. Confirm which system owns each data field so process variables do not become a shadow copy of customer records.
Messaging and event triggers
Many processes start or continue on a message from another system, such as a payment confirmation or a document upload. Check which messages the engine must correlate to a waiting instance, how duplicate or late messages are handled, and whether the broker in your environment is already approved for the data classes involved. Test a message that arrives before the process reaches its wait state, since that case causes most correlation errors.
Timers and asynchronous jobs across nodes
Deadlines, reminders and escalations depend on timers that must fire exactly once across a cluster. Flowable's async executor runs timers from a thread pool and uses lock owners and lock expiration times stored in the database, so a job locked by a failed node is picked up by another. In the proof of concept, stop one node during a running timer and confirm the job runs on another node, and measure the lock expiry you configure against your deadline tolerance.
Monitoring endpoints
Operations teams need to see stuck instances, failed jobs and queue depth before business users notice. The Flowable Spring Boot starters expose an actuator endpoint for monitoring running processes. Check that the endpoint is reachable only from your monitoring network, that its output carries no personal data from process variables, and that alerts connect to your existing monitoring stack. Confirm the same for any Camunda or Temporal endpoints you evaluate.
How clustering and running instances in production differ by engine
Flowable is usually embedded as a library in a Java application, a servlet container such as Tomcat or Jetty, a Spring application or a Java EE server, or it is called over HTTP through the Flowable REST application. Clustering comes from running several application nodes against one shared relational database. Nodes do not coordinate through memory. The async executor runs timers and asynchronous jobs from a thread pool, and it coordinates nodes through lock owners and lock expiration times stored in the database. When a node fails, its expired locks are recovered and other nodes pick up the jobs.
- Supported databases: Flowable's configuration docs list H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server. MySQL versions below 5.6.4 lack millisecond precision, which affects timers.
- Lock behavior: Confirm the lock expiration settings and how quickly a failed node's jobs are reclaimed, then test that with a forced node shutdown.
- Spring Boot operations: Flowable provides starters for the engines and REST, and an actuator endpoint at
/actuator/flowablefor monitoring running processes. - Identity: Identity management can be replaced through a custom identity service, with an LDAP reference implementation provided, so directory integration is a build task.
- Network exposure: Flowable's REST API and the application that embeds it need explicit access controls, because the engine does not decide who may call its endpoints.
Before sign-off, confirm the database type and version, the clustering test results and how the REST and actuator endpoints are restricted.
Camunda 8 is a separate deployment with its own components, including the Zeebe engine, Operate and Tasklist. Its clustering and scaling model is set by the platform's own deployment artifacts rather than by a shared application database. The licensing point matters as much as the topology: Zeebe, Operate and Tasklist source files are under the Camunda License 1.0, which limits use to non-production environments such as development, testing and evaluation. Production use requires a commercial license from Camunda.
- License gate: Confirm the commercial production license before planning a production cluster, because the source license does not permit it.
- Component scope: The Java client, Spring Boot starter, exporter API and protocol modules are under Apache-2.0, which is separate from the Camunda License 1.0 components.
- Release currency: Camunda 8.10.4 was released on October 13, 2026, with 8.9 and 8.8 patch releases on October 14, 2026, so the version chosen for a cluster should be confirmed against the current patch line.
- Operations: Ask the vendor or partner for the supported deployment method, the backup and restore procedure, and how each component scales.
- Migration path: Camunda's Diagram Converter analyzes Camunda 7 BPMN, DMN and form files, so existing Camunda 7 processes can be assessed for migration.
Before sign-off, get the license terms in writing for each component, the supported deployment method and the vendor's tested version matrix.
Temporal is an alternative durable execution platform rather than a BPMN engine. It is useful when long-running workflows need code-first orchestration, and it has a different set of clustering and security decisions. The server is MIT licensed, and self-hosting requires choosing persistence and a visibility backend. Temporal persistence is tested on Cassandra 3.11, 4.0 and 5.0.4 or later, PostgreSQL 13 to 16, and MySQL 5.7 and 8.0.19 or later. SQLite is meant only for development and testing.
- Visibility backend: Cassandra visibility was removed in 1.24. Elasticsearch or OpenSearch is recommended for anything beyond a few workflow executions, and the supported versions depend on the server release.
- Upgrades: Upgrade one minor version at a time, and run schema upgrades before server upgrades when release notes call for them. Helm chart versions below 0.73.1 do not work with server images 1.30 and later.
- Authorization: If no Authorizer is configured, the default noopAuthorizer allows every API request with no authentication or access control. A ClaimMapper, an Authorizer plugin, mTLS and OIDC single sign-on for the Web UI must be configured deliberately.
- Network exposure: Temporal's deployment docs say its services should run on hosts not reachable from the public internet, so network placement is a verification item.
- Payload encryption: Custom codecs and a codec server can encrypt payloads, which matters where process data is sensitive.
Before sign-off, confirm the persistence and visibility versions, the authorizer configuration and the network boundary, and test an upgrade in a non-production environment.
Operational requirements and how to verify them
This table compares the operational requirements a BPM engine must meet after go-live, with a verification method for each. Read each row as a question to put to the implementation partner and to the engine vendor before scope is signed. The main takeaway is that the engine choice changes the answers: Flowable 8.0.0 and Camunda 7 differ in upgrade path and support window, and Camunda 8 production use depends on a commercial license.
| Requirement | What to verify | Evidence to request |
|---|---|---|
| Backup and restore of the process database | Process definitions, running instances and history tables are backed up together and restored to a consistent point. Confirm the database type is on the supported list for the chosen engine. | Restore test log from a non-production copy, including a check that active instances resume and history queries return expected counts |
| Backup of Temporal persistence and visibility stores | If Temporal is in scope, persistence (PostgreSQL, MySQL or Cassandra) and the advanced visibility store (Elasticsearch or OpenSearch) need separate backup plans. SQLite is for development and testing only. | Documented backup schedule per store and a restore rehearsal covering both stores |
| Upgrade path and version compatibility | Flowable 8.0.0 requires Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3, so applications on Spring Boot 3 need a planned framework upgrade first. Temporal should be upgraded one minor version at a time. | Written upgrade plan listing the current and target versions, framework dependencies, and the schema upgrade order |
| Monitoring of running processes | Operators can see stuck or failing instances, overdue timers and failed async jobs. Flowable exposes an actuator endpoint at /actuator/flowable in its Spring Boot starters. Confirm equivalent visibility for the chosen engine and where alerts are sent. | Dashboard or endpoint screenshots, a defined alert list and a test where a failing job triggers an alert |
| Async executor and cluster health | The Flowable async executor uses lock owners and lock expiration times in the database to recover jobs from failed nodes. Confirm lock expiry settings and that a node stop does not leave jobs stranded. | Test result from stopping one node during active timers and confirming the jobs run on another node |
| Environment promotion from test to production | Process models, decision tables, forms and configuration move through environments in version control with the same engine version. Production licensing must be confirmed before promotion, since the Camunda License 1.0 limits use to non-production environments. | Promotion runbook, deployment pipeline logs and a signed license statement covering the production environment |
| Support windows and end of life | Confirm the engine version is inside its vendor support window and who provides security patches. Camunda 7 Community Edition received no releases after 7.24, and Camunda 7 Enterprise end of life was extended to April 9, 2030. | Written support statement from the vendor and the partner's patch commitment in the signed scope, without assumed response times |
| Release and patch cadence | Confirm how patch releases are published and how quickly the partner applies them in each environment. Camunda 8.10.4 and patch releases for 8.9 and 8.8 were published in October 2026. | Patch log for the last two cycles and a dated plan for applying the next patch to test first |
Checking process migration from Camunda 7 or Activiti
This sequence establishes whether existing Camunda 7 or Activiti processes can move to a supported engine, what the move will touch in running work, and how to reverse it if cutover fails. It ends with a tested, documented migration decision rather than an assumption that the platform change will be straightforward.
Inventory BPMN, DMN, forms and running instances
The engineering lead and business process owners list every BPMN model, DMN decision table, form definition and external script or listener the current engine uses. The inventory also records how many process instances are active, which versions they run on, and which timers and asynchronous jobs are pending. Done means each artifact has an owner, a version and a status, and the list of in-flight instances is exported from the production database rather than estimated from the process catalog.
Run a migration report on the inventory
Run the migration analysis against the exported files before anyone commits to a target. For a Camunda 8 target, Camunda's Diagram Converter analyzes Camunda 7 BPMN, DMN and form files and lists the migration tasks it finds. For a Flowable target, Flowable's free LEAP tool is designed to report ahead of time what a migration involves. Done means each report finding is classified as automatic, manual rework or blocked, and every blocked item has a named owner.
Confirm the Flowable in-place migration claim on your data
Flowable's 2022 engineering blog post states that Camunda 7 and Activiti data can be migrated in place, including active process instances and history. That is the vendor's own statement from 2022, so it must be verified against your schema, custom listeners, database type and history settings. Ask the migration partner to show the test on a copy of production, and ask the vendor to confirm current support for your exact source version. Done means a written result exists for each process family, with any exceptions recorded.
Test migration of active instances and history on a copy
Restore a copy of the production database into a non-production environment and run the migration end to end. Check that active instances continue at the expected step, that timers fire at the right time, that variables keep their types, and that the audit history is complete and readable for past decisions. Include a sample of long-running instances and instances that are waiting on human tasks. Done means the test log shows counts of migrated, completed and failed instances, and every discrepancy has been fixed or accepted in writing.
Test human tasks, integrations and access control
Verify that task assignment, candidate groups and forms work after migration, because user and group identifiers often change when the identity source is replaced. Re-run the integration calls to core systems, including message correlation and service tasks, against test endpoints. Confirm that the roles controlling who may deploy, modify or cancel processes match the approval design. Done means a signed test script covers each human task type and each integration, with results attached.
Define the cutover and its freeze window
The project lead and the business owner agree when new instances stop starting on the old engine, how running instances are drained or migrated, and who approves the switch. The plan states the order of steps, the checks at each step, and the person who can stop the cutover. Confirm the timing with the business calendar rather than assuming it. Done means a dated runbook has been approved, and every step names an owner and a verification check.
Document and rehearse the rollback
Define the conditions that trigger a rollback, such as failed instance counts above an agreed threshold or broken integrations, and specify how the old engine and database are kept available until the new platform is accepted. Rehearse the rollback on the copy environment before production cutover. Confirm with the vendor and the operations team how Camunda 7 end of life and Flowable's supported versions affect how long the old engine can remain in service. Done means the rollback rehearsal is recorded, and the decision to retire the old engine is signed off separately.
What buyers ask before hiring help with a BPM platform
How much does a BPM implementation cost, and what drives the price?
Cost depends on the written scope, not on the engine license alone. The open-source engines themselves carry no license fee for Flowable under Apache-2.0, but production use of Camunda 8 source code requires a commercial license from Camunda, so that line item can change the total. The main cost drivers are the number of processes to model in BPMN, the number of system integrations, the task UI and forms built for human work, any migration of running instances from Camunda 7 or Activiti, and the infrastructure and database the engine runs on. Ask for a quote that lists each process, integration and migration item separately, and ask which costs recur after go-live, such as upgrades, support and infrastructure. DeployOpen does not publish a price list, and a quote follows from the agreed written scope.
How long does a BPM implementation take?
Timeline is set by the number of processes, the number of integrations, how many decisions must be documented in DMN tables, and whether the work includes a migration from an existing engine. Process owners and subject matter experts must confirm each model, and identity and database teams must provision access and infrastructure before the engine can be tested. Migrating running instances adds a separate phase with its own testing and cutover planning. Ask any partner to show the phases, the dependencies on your teams and the milestones they will sign off in writing before work starts.
What does our internal team need to provide for a BPM project?
Your team provides the decisions and the access. Process owners approve the business logic and the expected outcomes for each process. Subject matter experts describe exceptions, approval limits and the data each step needs. Identity administrators connect the engine to your directory so task assignment follows your roles, and database administrators provision and back up the database the engine uses. Platform engineers own the hosting, clustering and monitoring. Confirm these roles and their time commitments before you sign, because delays in any of them usually move the delivery date more than the engineering work does.
Can we build a BPM platform ourselves with Flowable?
Yes, a capable Java team can embed Flowable, which is licensed under Apache-2.0, in a Spring or servlet application and expose its BPMN, CMMN and DMN engines through Java or REST APIs. The engine does not include a business user interface, so your team would build the task UI, forms, monitoring and any low-code modeling tools. Flowable's commercial products add those features on the same engines, and open-source users receive a community forum with professional services offered separately. Compare the build effort for the UI, security review, upgrades and on-call support against a partner implementation, and decide where your team's time is best spent.
How do we decide between Flowable and Camunda given licensing?
Start with the production license, because that decides the choice more often than features do. Flowable is available under Apache-2.0, which covers production use of the open-source engines. Camunda 8 source files are under the Camunda License 1.0, which limits use to non-production environments such as development, testing and evaluation and requires a commercial license from Camunda for production. Camunda 7 Community Edition no longer receives releases or security patches after its final feature release, 7.24, which was scheduled for October 14, 2025. Camunda 7 Enterprise Edition end of life was extended to April 9, 2030. Ask legal counsel to confirm the license terms against your actual deployment model, and ask each vendor in writing which terms apply to production.
How do we verify a partner's BPMN testing and migration approach?
Ask the partner to show how they test a process before it reaches production, including unit tests for decision logic, end-to-end tests across integrations, and a staged environment that mirrors production. For migrations, ask how they inventory running instances and history, how they convert models, and how they handle instances that cannot move cleanly. Camunda provides a Diagram Converter for Camunda 7 BPMN, DMN and form files, and Flowable's 2022 engineering post describes migrating Camunda 7 and Activiti data in place, including active instances and history. Request a sample test plan and a migration report from a comparable past project, with client details removed, and confirm the migration approach against the current vendor documentation.
How is a BPM engine clustered and kept running in production?
Flowable's async executor runs timers and asynchronous jobs from a thread pool across nodes. Nodes coordinate through lock owners and lock expiration times stored in the database, so an expired lock is recovered and the job is picked up by another node. This means the database is a critical dependency that needs backup, high availability and capacity planning. Ask the partner to describe the node count, the database type and version, how upgrades are rolled out, how monitoring is exposed (Flowable's Spring Boot starters include an actuator endpoint at /actuator/flowable), and how failover is tested.
Compliance evidence a BPM platform should produce
The audit history is the piece of a BPM platform that compliance teams will test first, so decide early what it must record. For each process instance, the engine should be able to show who started it, who completed each human task and when, which BPMN model version ran, which decision table version was applied, and which variables changed along the way. Those records are what let an assessor check controls such as change approval and segregation of duties, for example confirming that the person who approved a payment is not the person who submitted it. Confirm with your engine vendor and implementation partner which history levels the engine persists by default, where they are stored, how long they are kept, and whether they can be exported to your own log or archive store without losing the link to the process version.
If any process step uses a high-risk AI system under the EU AI Act, the logging requirements become a design input rather than a later add-on. Article 12(1) requires high-risk AI systems to technically allow automatic recording of events over the system's lifetime, and Article 19(1) requires providers to keep those logs for at least six months unless other law sets a longer period. Whether your processes fall into that category is a legal question, so confirm it with counsel before design starts. The practical check is whether the BPM history can capture the model input, output, version and the human who reviewed an automated decision, and whether retention matches your records policy. The AI Act Article 12 text and the AI Act Article 19 text are the natural next reads for your legal team.
DeployOpen prepares systems, controls and evidence for compliance assessments, including configuration of the engine, documented change procedures and exported history, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. Before scoping the engagement, ask your auditors which frameworks and control sets apply to the processes in scope, which evidence samples they will request, and what period they will test. Put that list into the written scope so the partner knows which records and configurations to produce.
How DeployOpen works on this
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source BPM platforms inside the client's own infrastructure. For a BPM requirements checklist, we turn the requirements into a written scope first, then build and test against it, and leave the client with documentation and the operating knowledge to run the engine.
How we scope
- We inventory the processes to model in BPMN, the case and decision tables needed, and the human tasks and forms each role will use.
- We record the integrations, identity sources and audit history expectations as written requirements with named owners.
- Engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before any build work starts.
How we build
- We deploy the chosen engine in your cloud accounts, data centers or air-gapped network, with the database and clustering design agreed up front.
- We implement process models, task UIs and integrations, and test versioning and migration of running instances before any production cutover.
- We check the license terms of each component against your intended production use and record the result in the design documents.
How we hand over
- You receive process models, configuration, deployment code and runbooks written for your own operations and security teams.
- We document how audit history is stored, which events are logged and how a reviewer can trace a completed instance.
- We walk your engineers through the upgrade and rollback procedure so the platform can be run without us on day one.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- Retainers can cover patching of the engine and its database, and upgrade planning when the vendor changes major versions.
- Any change to the scope after signature is handled through a written change request with its own deliverables.
