Before founding Sibo Consulting in 2017 I worked on IT projects for banks and financial institutions in Slovakia and Germany. I saw processes such as account opening, corporate loans and debt collection run both on a BPMN workflow engine and without one, simply as the status of a request in the database. Both approaches work, and the difference lies in when each starts to cost more than it delivers. That experience produced the decision rule we use at Sibo Consulting today when designing systems with approvals. This article is for architects, development leads and process owners facing that choice.

What BPMN is and what an engine actually does

BPMN (Business Process Model and Notation) is an OMG standard. The current formal version is 2.0.2, published in 2014. Version 2.0.1 was adopted as the international standard ISO/IEC 19510:2013. The standard defines both notation and execution semantics, so the same diagram can serve as documentation for the business and as an executable model. The diagram itself runs nothing, though. The engine does, and its value lies in what it handles for you at run time:

  • State and persistence: at wait states (a human task, a timer, waiting for a message) the engine stores the instance state in the database, so the process survives restarts and new application releases and can wait for days or weeks.
  • Timers and deadlines: time limits, reminders and recurring checks are part of the model, not separate scheduled jobs scattered across the code.
  • Escalations and boundary events: if a task is not completed in time, the process continues down another path, for example to a manager, without manual intervention.
  • Compensation: if a later step fails, the model defines which completed steps must be undone and by which action. Compensation is not a database rollback but another business action, such as cancelling a reservation.
  • Human tasks: assignment to a role or group, claiming, forms, delegation.
  • History and audit: who claimed and completed which task and when, which variables changed and which path the process took. The level of detail and the retention period need to be decided up front, because history grows with every instance.
  • Versioning: a new version of a definition is deployed alongside the old one, and running instances continue in the version they started in. Moving running instances to a new version (migration) is supported by engines, but only within certain limits and with an activity mapping.

For decision rules there is a separate OMG standard, DMN (Decision Model and Notation). A decision table, for example up to which loan amount one approver is enough and when the credit committee is needed, can be changed and tested separately from the process flow. Common BPMN engines include DMN, but decision tables can also be used without them.

Criteria: when an engine pays off

No single criterion is decisive on its own. In our experience an engine starts to pay off when several of them apply at once. If only one applies, a simpler solution is usually enough.

  • Participants: several roles take part (typically three or more), work passes back and forth between them and you need to know who currently holds it.
  • Duration: the process lasts days to months, waits for documents from the customer, for external systems or for people, and has to survive restarts and releases.
  • Deadlines: time limits, reminders and escalations are a regular part of the process rather than an exception. Hand-coded timers are hard to test and even harder to change.
  • Audit: the regulator, internal audit or compliance asks who approved what, when and along which path, and the answer must be available without piecing it together from logs.
  • Parallel branches: risk assessment, legal review and collateral valuation run at the same time, and the process waits for all of them or for the first rejection.
  • Process changes: the process changes more often than the rest of the application. Even with an engine, the executable model is usually changed by a developer working with an analyst, not by the business alone. An engine shortens the path of a change but does not remove the need for development or testing.

When a status column is enough, and how to do it properly

If a process has a handful of states, one owner, a short duration and only changes together with the code, an engine brings more operational overhead than benefit. A status column does not mean a text field anyone can write anything into, though. This minimum has proved itself:

  • A closed set of states (an enum or a lookup table with a database constraint), no free-form strings.
  • Allowed transitions defined in one place in the code, with the state changed only through that function.
  • An append-only history table: previous state, new state, who, when and why. This is the audit trail the column alone cannot provide.
  • Protection against concurrent changes, for example optimistic locking via a row version number, so that two approvers cannot move a request at the same time.
  • Deadlines as data: a due date on the row and one scheduled job that checks them, instead of timers scattered across the code.

Once this minimum starts to grow, with parallel states, exceptions to transitions and more scheduled jobs, it is a sign the process is outgrowing the column.

Between a column and BPMN: other options

There are also options between the two. A state machine library gives you explicit states, transitions and guards in code without separate infrastructure, but persistence, timers and audit remain your job. Durable execution platforms (Temporal, for example) express the process as ordinary code whose progress is stored as an event history and restored by replaying it after a failure. They handle long-running processes, retries and compensation well, but the workflow code must be deterministic and changes affecting running instances have to be versioned with the platform’s own mechanisms. There is no business-facing diagram and no standard human tasks, which matters a great deal for processes with many human steps. A BPMN engine makes the most sense when the model is a shared language with the business and human tasks make up a large part of the process.

Workflow engines as of October 2026

For a process that is meant to run in a bank for years, licensing and the product support lifecycle belong among the decision criteria just as much as features. The landscape has changed considerably over the past two years:

  • Camunda 7 Community Edition reached end of life in October 2025: the last community release, 7.24, came out on 14 October 2025 and no further security patches are issued for it. According to the vendor, the paid Enterprise edition is supported until April 2030. Forks have emerged from the community code, for example Operaton under the Apache 2.0 licence.
  • Camunda 8 is built on a different engine (Zeebe), so moving from 7 is a migration, not an upgrade. Since version 8.6 (October 2024), Self-Managed deployments including Zeebe require a paid licence for production use, while use for development is free. The source code is available under the Camunda License 1.0.
  • Flowable offers an engine under the Apache 2.0 licence supporting BPMN, CMMN (case management) and DMN. The vendor also sells commercial products.
  • jBPM, Drools and Kogito moved to the Apache Software Foundation as the Apache KIE project, which is still in the incubator. The first ASF release (10.0.0) came out in December 2024, and version 10.2.0 in April 2026.

We do not rank them, because the right choice depends on the existing technology, the operating model and the budget. In every case, though, the production licence, the support horizon and the migration path should be checked before the first process goes into the engine.

The cost of getting it wrong, in both directions

An engine for a simple process means more infrastructure with monitoring, backups and upgrades, possibly a licence, another debugging tool, and tests that must cover both the application and the model. A status column for a complex process means the opposite: after a year nobody knows why the request is in state 7, transition logic is spread across conditions throughout the application, escalations are handled by e-mail and the answer for the auditor is pieced together from logs. The first mistake costs more up front. The second grows more expensive over time and usually surfaces during an audit or a major process change.

Moving from a column to an engine when the process grows

  • First draw the actual flow in BPMN, including the exceptions that people currently handle outside the system. It often turns out that the code and reality have drifted apart.
  • Keep domain data (the request, the customer, the collateral) in the application database. The engine holds the process state and a reference to the request, not a copy of the data.
  • Start new cases on the engine and let cases already in flight finish the old way. Move running cases in bulk, mapping states to model activities, only when letting them finish would take unreasonably long.
  • During the transition, monitor both paths and reconcile them so that no request gets lost between the systems.
  • Do not delete the original history table, because the audit trail of older cases will be read from it for years.
  • Start with one process. The first one teaches the team to model, test and operate the engine, and the following ones go faster.

Typical mistakes when introducing an engine

  • Modelling every detail: every validation or service call as a separate step. The diagram becomes unreadable and the business stops using it. The model should hold business steps, waits and decisions, while technical details belong in code.
  • Logic in diagram scripts: calculations and conditions written as scripts or expressions inside the model are hard to test, debug and review. It is better to call tested code and move decisions into DMN tables.
  • Ignoring versioning of running instances: a model change without a strategy for cases in flight leads to several versions running in production at once, with nobody quite sure which ones and why.
  • Large data in process variables: whole documents in variables burden the engine database and its history. The process only needs identifiers and the data required for decisions.
  • The engine as an integration bus: orchestrating dozens of systems through the model instead of clear interfaces. The engine runs the process but does not replace the integration layer.

Recommendation

Draw the process in BPMN even when you will not use an engine. The diagram is a shared language with the business and reveals complexity before you discover it in code. Then go through the criteria: if the process is long-running, involves several roles, has deadlines and audit asks about every step, an engine usually pays off, and the licensing and support model should be chosen together with it. If not, build a proper status column with history and transitions in one place, and decide in advance which signals will tell you the process is outgrowing it.