State machines and process engines: the cost of a hidden distinction

A platform decision can determine how far an operating model will scale. The risk becomes visible when the business expects to increase throughput, while the selected technology requires engineers to build and maintain the coordination mechanisms that make that increase possible.

We encountered this in a client engagement involving a long-running business process. The candidates included a BPMN process engine and a low-code platform whose workflow implementation relied on record states and transitions. Both advertised workflows, subprocesses, parallel branches, timers, and APIs.

The feature comparison suggested similar capabilities. The implementation revealed a material difference in who owned execution: the platform or the application team.

Execution behavior determines the work you inherit

A state machine describes the states a system can occupy and the transitions between them. In a record-oriented workflow, this may be sufficient to represent an application moving from review to approval to completion.

A process engine adds facilities for executing and tracking activities over time. Depending on the engine, these can include separate process instances, parent-child relationships, waiting points, event handling, and recovery operations.

The distinction requires care. State machines can support hierarchy and concurrency, and process engines themselves maintain state. The practical question is which coordination guarantees a particular product provides, and which the team must implement.

A feature labeled “subprocess” does not answer that question. Its value depends on what happens when several subprocesses run concurrently, one fails, the parent is interrupted, or the operation is restarted.

A parent waiting for its children exposes the difference

In the client implementation, a parent process started several child processes, waited for their results, and then continued. The workflow platform represented waiting as a state, with progress controlled by queries over child records.

The implementation did not reliably distinguish children belonging to the current execution attempt from records left by earlier attempts. A previous failure could therefore interfere with a restart. Handling an external event while the parent waited introduced further uncertainty about which work remained active.

To advance the process, child logic reached back into the parent and triggered its next transition. Each child consequently needed knowledge of the parent’s internal state model. Reusing that child in another process required additional coordination logic.

These were limitations of the selected implementation. They illustrate the engineering burden that arises when execution identity, lifecycle ownership, and completion rules have to be assembled in application code.

Evaluate the guarantees behind the feature

A BPMN engine offers a different starting point. In Camunda, a call activity creates a child process instance and continues when that instance completes. An interrupting boundary event terminates the call activity and its child; a non-interrupting event leaves the child running. These behaviors are documented in the engine’s call activity semantics.

For a collection of children, a multi-instance activity tracks the individual executions. Completion conditions and the scope of boundary events determine when the group finishes and what happens to remaining instances. For example, Camunda terminates active instances when a multi-instance completion condition is met. See its multi-instance documentation.

The model still requires deliberate design. Error handling must distinguish a business rejection from a technical incident. Data mappings must prevent concurrent results from overwriting one another. Terminating a process instance does not automatically reverse a payment, recall a message, or stop work already running in another system.

The benefit is an explicit execution model against which those decisions can be made and tested.

The commercial impact extends beyond the first workflow

Custom coordination creates an ongoing obligation. Every additional workflow may need its own handling for timeouts, retries, duplicate events, stale records, and partial completion. A change to a shared child process may require regression checks across all the parents that depend on its internal behavior.

This affects two forms of capacity: the volume of operational work the system can handle reliably, and the rate at which the engineering team can introduce change. Both belong in the investment case.

A process engine also has costs. Teams need modeling expertise, production operations, and an understanding of the engine’s execution and deployment behavior. For a simple approval flow, that overhead may exceed the benefit.

The economic comparison should therefore include the coordination work each option leaves to the organization, alongside licensing, infrastructure, and implementation costs.

Make the difficult scenario part of selection

Before committing to a platform, ask each candidate to execute the same representative scenario:

• Start several child processes and associate every result with the correct parent and attempt.
• Handle a child failure while making the intended behavior of its siblings explicit.
• Restart work without treating stale results as current results.
• Handle a deadline or external event while work is in progress.
• Show an operator what happened and how to recover safely.

Record which behaviors come from the engine, which require configuration, and which depend on custom code. Include the effort to operate and change that code in the comparison.

When a strategic objective depends on coordinating work at scale, execution behavior is part of the business decision. The platform should earn its place by demonstrating that behavior under the conditions the organization will actually face.