Skip to main content

BPMN vs. Temporal: When Do You Need a BPMN Engine?

· 7 min read
Richard Bízik
Richard Bízik
Founder of QuantumBPM

If you're building anything stateful and long-running on the JVM, in Go, or in TypeScript, Temporal has probably crossed your desk. It's the de-facto durable execution platform — Uber, Snap, Coinbase, HashiCorp, Stripe, Datadog and a long tail of others run production workloads on it. The natural question, when someone hands you a "build a workflow engine" requirement, is: do I just use Temporal, or do I need a BPMN engine?

Short answer: both can be right. The dividing line is who the model belongs to. This post explains why we built QuantumBPM on top of Temporal rather than competing with it, and how to decide which level you should be writing your workflow at.

Disclosure up front​

QuantumBPM is built on Temporal. Every BPMN process instance is a Temporal workflow. So this post isn't "us vs them" — we're a layer on the same stack.
For the architecture detail, see the Why QuantumBPM is built on Temporal section of our comparison page.

What Temporal actually is​

Temporal is a durable execution platform. You write workflows as ordinary code (Go, Java, Python, TS, Ruby, .NET, PHP) and the platform makes them survive crashes, restarts, network partitions, and weeks-long sleeps without you writing any "where was I?" recovery logic.

The mental model:

  • A workflow is a function. It can await activities, sleep for arbitrary durations, receive signals, and spawn child workflows.
  • An activity is a piece of work with side effects — a database write, an HTTP call, a payment charge. Activities are retried, heartbeated, and recorded.
  • A signal is an external event delivered to a running workflow.
  • A query is a read-only inspection of workflow state.
  • The whole thing is event-sourced: every step is recorded, and replaying the events deterministically reconstructs the state.

This is a small, sharp set of primitives. Once you internalise them, you can build anything stateful — and Temporal's whole value proposition is that you build it in code.

What a BPMN engine adds​

BPMN engines also model long-running stateful workflows. The difference is that the workflow lives as a declarative model — a diagram with well-defined runtime semantics — rather than as code.

That difference matters less than people think for engineers, and more than they think for organisations:

  • A BPMN process is legible to people who don't write code. A product manager, an ops lead, a compliance officer can read the diagram, propose changes, sign off. With Temporal you ship a code review.
  • A BPMN process is versioned as a model. Deploying a new version, migrating in-flight instances to it, and auditing what version ran for a given instance are first-class concerns. With Temporal, workflow versioning is a code-side concern (the Patch/GetVersion APIs) that engineers reason about line-by-line.
  • A BPMN process comes with formal semantics for everything organisations actually need: scoped error handling, escalation, compensation, multi-instance, ad-hoc subprocesses, boundary events, message correlation, named errors. You'd build all of that yourself in Temporal — and most teams do, badly, then rebuild it.
  • A BPMN engine comes with a UI for operators: see running instances, scrub through history, resolve incidents, send messages, modify token state, migrate to a new version. Temporal Web is a developer tool for inspecting workflow histories — it's not aimed at non-engineering operators.

So the line is roughly: Temporal gives you a primitive. A BPMN engine gives you a product.

When raw Temporal is the right answer​

You don't need a BPMN engine — and shouldn't pay for one — if all of the following are true:

  • The workflow is owned and changed by engineers, not by product/ops/compliance.
  • The shape of the work isn't really business-process-shaped — it's, say, a data pipeline, a service orchestration, a saga across microservices, a deployment workflow.
  • You're already building polyglot service workers in Go/Java/Python/TS and the code-first model fits your team's mental model.
  • Operational tooling for non-engineers (a process map UI, an instance scrubber, an incident-resolution console) isn't a requirement.

Temporal will be cheaper, simpler, and more flexible than putting a BPMN engine on top of it for these cases. It's the right tool.

When a BPMN engine earns its keep​

A BPMN engine on top of Temporal — what we are — earns its keep when:

  • The process is business-shaped: onboarding, claims, approvals, KYC, underwriting, fulfilment, case management. The vocabulary lines up with BPMN's primitives (tasks, gateways, events, sub-processes) because that's what BPMN was designed for.
  • Non-engineers need to read, change, or sign off the model. Compliance reviewing the auth flow as a diagram is qualitatively different from reviewing it as a Go file.
  • You need operational UIs out of the box: a list of running instances, a way to resolve incidents, a way to send a message to a stuck instance, a way to migrate in-flight work to a new version.
  • You need decisions with audit trails alongside the process. BPMN's business-rule task pairs with DMN — see BPMN vs. DMN for that integration.
  • Versioning matters at the process level, not just the code level — every change is a new immutable definition version, evaluable side-by-side, with a UI showing what version each instance ran on.

You're not throwing Temporal away in this case. You're getting Temporal plus a layer that turns its primitives into a product.

What QuantumBPM is, concretely​

To make the layering tangible: QuantumBPM is a Go service that hosts BPMN process definitions, exposes them via a REST/OpenAPI surface and a web modeler, and translates BPMN execution into Temporal workflows. On top of Temporal we add:

  • Full BPMN 2.0 element coverage — every event type (timer, message, signal, error, escalation, compensation, link, terminate), interrupting and non-interrupting boundary events, event subprocesses, ad-hoc subprocesses, call activities, multi-instance.
  • Scope tree and event bubbling — compensation, escalation, and errors target logical scopes and traverse the active ancestry chain.
  • Concurrency-safe interpreter state for parallel and inclusive gateways.
  • Live instance modification — insert or cancel tokens on a running workflow.
  • Version migration — explicit migration plans move in-flight instances to a newer process version.
  • Replay slider UI — reconstructs process state at any point in Temporal's event history.
  • Inline DMN integration — business-rule tasks invoke registered DMN definitions in-process. No external decision-service round-trip.
  • External worker queue — HTTP poll API for service tasks that live outside the Temporal worker pool (e.g. languages without a Temporal SDK, or workers behind a firewall).
  • Visual modeler, projects, RBAC, audit history, multi-tenancy, OpenTelemetry, metrics — the platform layer that wraps the engine into a product.

The split is clean: Temporal owns durability and execution. QuantumBPM owns the BPMN spec, the user-facing surfaces, and the operational controls.

A decision shortcut​

Stop reading and pick the simpler tool when you can:

  • The workflow is small, lives next to one service, and only engineers touch it → write it as a Temporal workflow.
  • The workflow is the product — visible to non-engineers, audited, versioned, owned by the business → use a BPMN engine.
  • You're already on Temporal and outgrowing the code-only model → BPMN-on-Temporal is the natural next step.

If you're not sure, the cost of starting with raw Temporal and migrating later is usually lower than the cost of adopting a BPMN engine you don't need yet.

Where to go from here​

If you're already running Temporal and curious what the BPMN layer adds, the platform overview is the fastest way in.