Short answer: Airflow, Prefect, and Dagster are DAG-based data orchestrators. BPMN engines are business-process engines. They look similar from far away and feel completely different up close. This post is about the difference and how to pick.

The shape of the problem matters​

The cleanest way to tell these tools apart is to look at the shape of what each one models.

A DAG-based orchestrator like Airflow, Prefect, or Dagster models a directed acyclic graph of tasks, run on a schedule (or in response to a trigger). The classic example: an ETL pipeline. "At 02:00 every day, extract from these sources, transform, load into the warehouse, run dbt, send a Slack notification." Each task is a unit of code. The DAG is the dependency graph between them. The scheduler runs the right tasks in the right order at the right time.

A BPMN engine models a business process. The classic example: an order fulfilment flow. "When an order arrives, evaluate it. If it's flagged for review, send it to a human. Charge the customer. If charging fails three times, escalate. Ship it." Each step is a typed BPMN element. The diagram is the spec. The engine runs one instance per real-world event (per order, per claim, per onboarding).

The differences cascade from there.

Five concrete differences​

1. Cadence​

DAG orchestrators are schedule-shaped. The first-class concept is "this DAG runs every day at 02:00", and most of the platform is built around that — backfills, catchup runs, freshness SLAs, schedule overlap handling.

BPMN engines are event-shaped. The first-class concept is "an instance starts when an order arrives". Schedules exist (timer start events) but they're not the centre of gravity. Most instances are triggered by external messages, signals, or API calls.

If your problem is "do this batch on a schedule", DAG. If your problem is "react to this event with a multi-step flow", BPMN.

2. Instance lifetime​

A DAG run typically lives for the length of a single execution — minutes to hours. When it finishes, it's done. You query its history for debugging.

A BPMN instance routinely lives for days to weeks, because business processes do. An onboarding flow might spend two business days waiting for a document. A claims flow might spend a month in adjudication. Long-lived stateful instances with a current position, accumulated variables, and active timers are the normal mode of operation, not the exception.

3. Humans in the loop​

DAG orchestrators don't really model humans. You can fake a human approval with a sensor task that polls a database for a flag — and people do — but it's an awkward fit.

BPMN has user tasks as a first-class element. The engine holds a token until a person claims and completes the task. Assignment, reassignment, and escalation are all spec-defined. The task list integrates into your own UI via API. Half of business processes have a human step somewhere. That's why BPMN was designed around it.

4. Error and compensation semantics​

DAG orchestrators model failure as task retry plus on-failure callbacks. That covers most data-pipeline cases: a task failed, retry it, or alert if retries exhausted.

BPMN models failure as a layered set of concepts:

• Errors with named types, caught at boundary events or in event sub-processes, traversing scope hierarchies (an error inside a sub-process bubbles up until it's caught).
• Escalations that, unlike errors, can be non-interrupting — work continues while someone is alerted.
• Compensation — the formal mechanism for undoing work that already succeeded when something later in the process fails. You don't "retry" a charge that already settled. You compensate it with a refund.

If your domain has the shape "we sometimes have to undo earlier work because something later went wrong", you want compensation, and BPMN is the spec that defines it.

5. Who owns the diagram​

A DAG is owned by engineers. It's Python (in Airflow, Prefect, Dagster), reviewed as code, and changed via PR.

A BPMN process is owned by the business. The diagram is the contract between engineering and the people who actually own the work — product, ops, compliance. It's reviewed by them, signed off by them, and audited by them. The XML serialisation is for the engine. The visual diagram is for the conversation.

This is the deepest difference, and it's the one that determines whether BPMN or a DAG orchestrator is right: who needs to read, change, and sign off this thing?

When a DAG orchestrator is the right answer​

Use Airflow, Prefect, or Dagster when:

• The work is data-shaped — ETL, ingestion, dbt orchestration, ML training pipelines, reporting jobs.
• The cadence is scheduled or pipeline-triggered, not driven by external business events.
• The audience is engineers — data engineers, ML engineers, analytics engineers — not the business.
• Per-run lifetime is bounded and short (minutes to hours).
• The state model that matters is dataset freshness and lineage, not "where is this individual order in its lifecycle".

For these cases a BPMN engine is the wrong shape. Don't use one.

When a BPMN engine is the right answer​

Use a BPMN engine when:

• The work is business-process-shaped — onboarding, claims, approvals, fulfilment, KYC, case management, underwriting.
• Each instance corresponds to a real-world event (an order, a claim, a customer) and lives for as long as that event takes to resolve.
• Humans are part of the flow — claiming, approving, completing tasks.
• Audit, compliance, and governance are non-negotiable requirements, not nice-to-haves.
• The diagram needs to be readable by non-engineers, who will review and sign off changes.

These are not data-pipeline characteristics. They're business-process characteristics. Different shape, different tool.

The boring answer: most large orgs need both​

A retailer running data pipelines for analytics and an order-fulfilment process for live transactions needs both — Airflow for the warehouse jobs, a BPMN engine for the order flow. They don't compete. They don't even sit in the same plane.

The mistake is forcing one shape into the other:

• A DAG of "wait for human approval" tasks is a bad BPMN process.
• A BPMN process of "extract, transform, load" steps is a bad data pipeline.

Match the tool to the shape and the rest is straightforward.

How QuantumBPM fits​

QuantumBPM is a BPMN+DMN platform — squarely in the business-process camp. We're not trying to be Airflow's replacement. We don't ship dataset lineage, schedule catchup, or the data-engineering-shaped tooling those platforms exist to provide. We do ship:

• BPMN 2.0 process modelling and execution — events, tasks, gateways, scopes, compensation, multi-instance.
• DMN 1.5 decision modelling — for the rules a business-rule task evaluates inside a process.
• A web modeler, operational UI, and replay scrubber — for non-engineers who own the model.
• Built on Temporal — durable execution under the BPMN layer.

If your problem is data orchestration, pick one of the three orchestrators above. If your problem is business processes, the comparison page covers how QuantumBPM stacks up against Camunda and other BPMN engines.

Where to go from here​

• What is BPMN? — the BPMN primer.
• BPMN vs. DMN — process vs. decision modelling.
• BPMN vs. Temporal — the code-first orchestration comparison.
• BPMN vs. n8n — the visual-automation comparison.
• QuantumBPM platform overview — start here if you're modelling a real process.

It's also a tool that teams outgrow in a specific, predictable way. This post is about that ceiling: where n8n stops being the right answer, and what changes when you move to a BPMN engine.

What n8n is excellent at​

Before the criticism, the credit. n8n is a fantastic fit when:

• You need to glue APIs together — pull from one SaaS, push to another, transform JSON in the middle.
• The workflow is short — runs in seconds to minutes, triggered by a webhook, schedule, or polling.
• The integration is the hard part — you'd rather drop a "Slack" node onto a canvas than read a Slack SDK reference.
• The team running the workflow is mixed — engineers, ops, marketers, support — and a low-code visual editor lowers the bar.
• The audit and durability requirements are modest — "did this workflow run, and what did it do?" is enough.

For these cases n8n is genuinely faster than building anything in-house, and "use a BPMN engine instead" would be a bad recommendation. Don't do that.

Where n8n starts hurting​

n8n earns its name from "node-mation" — a node graph for automations. That's a different shape from a business process, and the gap shows up as your needs grow:

• Long-running and stateful. n8n can sleep, schedule, and wait — but it isn't designed around weeks-long instances with rich scoped state. A BPMN engine is. Process instances live indefinitely, surviving restarts, with full event history.
• Multi-actor, human-in-the-loop work. When a step is "wait for a compliance officer to approve this", n8n leans on third-party form/approval nodes. BPMN has user tasks as a first-class citizen with an API your own UI consumes (claim, complete, reassign).
• Formal error semantics. BPMN distinguishes errors (something failed) from escalations (something needs human attention) from compensation (we have to undo work that already succeeded). Boundary events, event sub-processes, and compensation handlers all have spec-defined semantics. n8n has retries and "on error" branches, but not the same scoped, hierarchical model.
• Versioning and migration of in-flight work. When the rules change, what happens to the orders already mid-flow? A BPMN engine treats every save as a new immutable definition version and gives you explicit migration plans. n8n's model is closer to "edit the workflow", which is fine for short-running automations and uncomfortable for long-running processes.
• Audit trails the business actually needs. Regulated industries need "who decided what, when, with what inputs" for every instance, indefinitely. A BPMN engine paired with DMN gives you this by default. In n8n you build it.
• Decisions as first-class artefacts. When the rules ("which loan tier?", "high-risk transaction?") are owned by non-engineers and change often, you want them as a DMN model, not as branching nodes inside a workflow.
• Governance and review. A diagram with a stable XML serialisation, owned in git, reviewed as a model with proposed-change diffs — that's the BPMN flow. n8n's stored format isn't designed to be reviewed as a contract between engineering and the business.

The pattern is consistent: n8n optimises for getting one automation done quickly. BPMN optimises for operating long-running, audited, multi-actor business processes at organisational scale. Different shapes, different tools.

A useful rapid test​

Three questions, and if the answers tilt toward the right column, n8n is the right call. If they tilt left, you're in BPMN territory:

If you're in the middle, you're probably running both — n8n for the fast integrations, a BPMN engine for the processes that matter to the business. They genuinely don't compete. They coexist.

What you give up by moving to BPMN​

A BPMN engine isn't free. The trade-offs you make moving from n8n:

• No giant integration library. n8n's 400+ pre-built nodes are real engineering value. A BPMN engine's service tasks are typically powered by your own workers — you write them. You can absolutely call any API from a service task, but you write the call.
• Higher modelling discipline. BPMN is a richer, more formal language. There are more ways to do something correctly and incorrectly. Onboarding a team takes longer than n8n.
• More moving parts to operate. A BPMN engine usually wants Postgres and a durable execution substrate. n8n is comparatively self-contained.

These are real costs, and they're why "rip out n8n" is rarely the right answer for the parts of your stack that n8n was a good fit for in the first place.

How QuantumBPM positions​

QuantumBPM is a BPMN+DMN platform built in Go on Temporal. It's deliberately not in the same category as n8n — we don't ship a vast integration library, and our target user is engineering teams running long-running stateful processes that the business owns. Concretely:

• BPMN 2.0 modeler and engine — every event type, interrupting and non-interrupting boundary events, ad-hoc and event sub-processes, call activities, multi-instance, compensation.
• DMN 1.5 integration — decisions are first-class artefacts, with FEEL, decision tables, simulation, and execution history.
• Operational UI — running instances, replay slider, incidents, message/signal correlation, token modification, version migration.
• External worker queue — a poll-based HTTP API for service tasks in any language. This is the n8n-shaped extension point: instead of pre-built nodes, you write workers that pull jobs.

If you're at the point where n8n is hurting and you want to evaluate a BPMN engine that doesn't drag in a JVM platform, the comparison page is a good starting place.

Where to go from here​

• What is BPMN? — the BPMN primer if you're new to the spec.
• BPMN vs. DMN — how decisions fit alongside processes.
• BPMN vs. Temporal — the code-first orchestration comparison.
• QuantumBPM overview — what's supported in the engine.
• External workers — how to plug in your integrations.

If you've already decided n8n isn't enough and want to try modelling a real process, start at the platform overview.

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​

• What is BPMN? — the core BPMN primer.
• BPMN vs. DMN — pairing process and decision modelling.
• QuantumBPM comparison — the full architecture and competitor comparison, including the detailed Temporal section.
• BPMN overview — the engine's supported element surface.

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

This post is the engineer's-eye view: what DMN is, why teams reach for it instead of if/else in code, and what the moving parts are in a real decision.

Why DMN exists​

Most non-trivial systems carry rules that change far more often than the surrounding code:

• A pricing engine adjusts discount tiers every quarter.
• A KYC workflow tightens thresholds whenever a regulator publishes new guidance.
• A clinical triage system updates symptom-to-priority mapping when protocols change.

These rules are owned — in practice — by people who don't ship code: product managers, compliance officers, clinicians, underwriters. DMN is the contract between them and the engineering organization. The domain expert reads and edits a decision table. The engine evaluates it deterministically. The audit log shows which rules fired and why.

The two pieces of DMN you'll actually use​

The DMN spec is large, but in day-to-day work two artefacts carry the weight.

1. The Decision Requirements Graph (DRG)​

A DRG is a directed graph that lays out which decisions exist and what they depend on. Nodes come in a small set of flavours:

Arrows are dependencies: "this decision needs that input data" or "this decision depends on that other decision". The DRG is what you see in the modeler before you open any individual decision.

2. The decision logic — usually a decision table​

Every decision contains a boxed expression. The most common form is the decision table, but the spec also defines literal expressions, contexts, lists, relations, function definitions, and invocations — each rendered as its own visual box.

A decision table has a hit policy, input columns, output columns, and rules:

The U is the hit policy — Unique, meaning rules may not overlap. Exactly one row matches. Other common policies you'll see:

• F (First) — top-down, first match wins.
• P (Priority) — rules may overlap. Output is chosen by configured priority.
• C (Collect) — return all matches as a list (with optional aggregations for sum/min/max).
• A (Any) — overlaps allowed, but every matching rule must produce the same output.

The expressions inside cells aren't an ad-hoc DSL — they're written in FEEL.

FEEL — the expression language​

FEEL (Friendly Enough Expression Language) is the small declarative language defined by the DMN spec. It's the language used for input entries, output entries, literal expressions, conditions — anywhere DMN needs to evaluate something.

FEEL supports the things you'd expect — arithmetic, booleans, strings, lists, contexts (records), dates, times, durations, ranges, if/then/else, for comprehensions, quantified expressions (some, every), and a sizeable standard library of built-ins.

A few concrete examples:

// Arithmetic
gross * 0.20

// Range test (used as an input entry in a decision table)
[18..65]

// List comprehension
sum(for o in orders return o.total)

// Quantified expression
every order in orders satisfies order.status = "approved"

// Context literal — values returned from decisions are often contexts
{ approved: true, reason: "credit_ok" }

What makes FEEL useful in this setting is that it is deliberately not a general-purpose programming language. There are no side effects, no I/O, no loops with mutable state — just pure expressions. That property is what makes a decision auditable and replayable.

If you want to play with FEEL without spinning up a project, the QuantumBPM FEEL playground is a browser-based editor — same LSP, same evaluator, no signup. Paste an expression, see the result.

What evaluating a decision actually looks like​

In QuantumBPM, evaluating a decision is an HTTP call against a definition. The minimum you need is the decision name and an input context:

POST /api/projects/{project}/definitions/{definition}/evaluate
Content-Type: application/json

{
  "decisionName": "Loan Approved",
  "context": {
    "Age": 32,
    "Credit Score": 720
  }
}

The response gives you the result, plus the per-decision execution detail — which rules fired, what each upstream decision returned, and the dependency tree the evaluation traversed. That last part matters: a real-world DRG is not a single decision but a graph, and every transitively-required decision is evaluated and recorded.

For a fuller worked example, see the DMN overview and Evaluation and history docs.

"Why not just write it in code?"​

This is the question every engineer asks the first time they see DMN. Three honest answers:

1. Rules change on a different cadence than the surrounding code. Putting them in a model that non-engineers can read, edit, simulate, and version separately is genuinely faster than the round-trip of a code change every time a threshold moves.
2. The audit trail is non-negotiable in regulated industries. A DMN engine records the inputs, the rules that fired, and the outputs for every evaluation. Reproducing that with hand-rolled code is a project, not an afternoon.
3. The model is testable as a model. You can simulate proposed rule changes against historical traffic without redeploying anything — a workflow QuantumBPM exposes natively.

DMN is not the right tool for everything. If the logic is small, stable, and lives next to a single piece of code, native code is fine. DMN earns its keep where logic is shared, changing, audited, or owned by a non-engineering team.

How DMN sits next to BPMN​

The two most-cited OMG standards in this space are DMN and BPMN (Business Process Model and Notation). They solve different problems and are designed to be used together:

• BPMN describes a process — a sequence of tasks, gateways, events — over time. "What happens, in what order, in response to what."
• DMN describes a decision — at a single point in time. "Given these inputs, what's the answer."

A BPMN business-rule task calls a DMN decision. The process engine handles flow, scheduling, retries, timers, human tasks. The decision engine handles "what's the loan amount" or "is this transaction high-risk." We covered the split in detail in BPMN vs. DMN: when to use which.

Where to go from here​

• What is BPMN? — the companion piece on process modelling.
• The DMN overview — what's supported, the modeler, and links to the element reference.
• FEEL syntax — the expression language in depth.
• FEEL playground — try and share FEEL expressions in the browser. Share links so teammates can pick up your work without any setup.
• Decision tables — hit policies, input/output columns, and worked examples.

If you want to try a decision in QuantumBPM end-to-end — model it, evaluate it, inspect the audit trail — start at the getting started guide.

The BPMN 2.0 spec defines well over a hundred symbols. The honest truth is that you'll use about fifteen of them in 90% of real processes. This post walks through that core, then explains how a BPMN model actually executes.

What BPMN is good at​

BPMN models the flow of work over time: who or what does the next step, what triggers it, what happens if it times out, and what runs in parallel. It's the right tool when:

• A piece of work spans multiple actors — a service, a human, an external system.
• It runs over wall-clock time — minutes, hours, weeks.
• It needs to survive crashes, restarts, and retries without losing its place.
• The flow itself is a thing the business owns — onboarding, claims processing, an approval chain — and changes over time.

If your "process" is a synchronous function call that returns in milliseconds, BPMN is overkill. If your "process" reaches a step labelled "wait two business days for the customer to upload a document", BPMN earns its keep.

The core elements​

A BPMN process is a directed graph of flow elements connected by sequence flows (the arrows). The flow elements come in three families.

Events — circles​

Events represent something that happens. Three positions on a flow:

• Start events — how the process begins.
• End events — how it terminates.
• Intermediate events — something in the middle: wait for a message, throw a signal, raise an error.

Each event has a trigger type. The ones you'll meet in real processes:

	Trigger	What it means
	None	Plain start/end with no specific trigger.
	Message	Wait for a named message correlated to this instance.
	Signal	Broadcast or wait for a named signal (one-to-many).
	Timer	Fire after a duration, on a date, or on a cycle.
	Error	Throw or catch a named error — for failure handling.
	Escalation	Like an error, but typically non-interrupting (the work continues while someone is alerted).
	Compensation	Trigger compensating actions when something has to be "undone".
	Terminate	An end event that immediately stops the entire process.

Boundary events sit on the edge of a task or sub-process and intercept it — "if this task takes longer than 24 hours, fire a timer". They come in interrupting (cancel the task) and non-interrupting (run alongside) variants.

Tasks — rounded rectangles​

A task is a unit of work. The task type tells the engine who or what does it:

	Task	Performed by
	Service task	An automated worker — typically code (a Temporal worker, a polled HTTP worker, etc.).
	User task	A person, via your UI. The engine holds the token until the task is claimed and completed.
	Script task	A short inline expression — in QuantumBPM, written in FEEL.
	Business-rule task	Calls a DMN decision and writes the result back into process variables.
	Send task / Receive task	Send or receive a message.
	Manual task / Generic task	Untracked manual work / no specific semantics — useful for documenting steps the engine doesn't run.

Gateways — diamonds​

Gateways control branching and merging:

	Gateway	Behaviour
	Exclusive (XOR)	One outgoing path is taken based on a condition. The default if/else of BPMN.
	Parallel (AND)	All outgoing paths run concurrently. On join, all incoming must arrive.
	Inclusive (OR)	Any number of outgoing paths can run, based on per-flow conditions.
	Event-based	Wait for one of several events. Whichever fires first wins.

Three families. About fifteen meaningful elements. That covers most processes you'll actually model.

Structure: sub-processes and call activities​

Real processes get nested. BPMN gives you three ways to compose:

	Element	What it is
	Embedded sub-process	A group of elements drawn inline, sharing the parent's data.
	Call activity	An invocation of another process definition. The called process runs as its own scope and can be reused across processes.
	Event sub-process	Sits inside a parent scope and triggers on an event (a message, an error, a timer). Useful for "if anything goes wrong, do this".

Sub-processes are also where you attach boundary events for scoped error handling, escalation, and compensation.

A small example​

Here's the spine of an order-fulfilment process modelled in QuantumBPM:

Reading left to right:

1. Start event (message: "OrderPlaced") — the process kicks off when an order arrives.
2. Business-rule task — call a DMN decision to decide whether the order needs manual review.
3. Exclusive gateway — branch on the decision result.
   • No review needed → continue.
   • Review needed → user task (a human approves or rejects), then continue.
4. Service task — charge the customer.
   • With a timer boundary event — if charging takes more than 5 minutes, escalate to manual charge.
5. Service task — schedule shipment.
6. End event.

That's an end-to-end process using start/end, a business-rule task, a service task, a user task, an exclusive gateway and a timer boundary event. Six element types — and you can already model surprisingly complex real-world flows.

What "executing a BPMN model" actually means​

The visual model is just one face of BPMN. Underneath, every BPMN element has well-defined runtime semantics: what it does when a token arrives, what it produces, what it waits for. A BPMN engine is the runtime that gives those semantics a concrete implementation.

In QuantumBPM, that runtime is built on Temporal — a durable execution platform. Each process instance becomes a Temporal workflow. The practical consequences:

• Crashes are non-events. Workflow state is event-sourced, so a worker restart resumes the instance exactly where it stopped — no recovery code to write.
• Long-running is normal. A timer event waiting two weeks doesn't pin a thread or a database row in a non-obvious way. Durability is the default.
• Every step is recorded. The instance history is replayable — the same property that lets us offer a "scrub the timeline" UI for running and completed instances.

What we layer on top is the BPMN-specific machinery: the element catalog with full validation, scope trees for compensation/escalation/error bubbling, a concurrency-safe interpreter for parallel and inclusive gateways, and the operational tooling — incidents, message/signal correlation, token modification, version migration.

Where to go from here​

• What is DMN? — the companion piece on decision modelling.
• BPMN vs. DMN — how the two standards complement each other.
• BPMN overview — what's supported in the QuantumBPM engine and the modeler.
• Element reference — events, tasks, gateways, structure, flows.
• External workers — how to implement service tasks in your own language.

If you want to draw and run a process end-to-end, start at the platform overview.

This post walks through what each standard is, where each one fits, the boundary between them, and a worked example of the two working together.

The 30-second answer​

If you take only one thing away: a BPMN business-rule task calls a DMN decision. That single pattern is how most systems combine them.

What BPMN models​

BPMN is a flow diagram for work that unfolds over time. It answers questions like:

• "When an order arrives, what runs first, and under what conditions does the next step run?"
• "If the customer hasn't responded in 48 hours, what happens?"
• "Three things need to run in parallel — when they're all done, then what?"

BPMN's primitives are tasks (units of work), gateways (branching and merging), events (things that happen), and structural containers (sub-processes, call activities). Crucially, BPMN is stateful: a process instance has a current position (the tokens on the diagram), variables, and a history. It can wait. It can fail and resume. It can run for weeks.

For more on BPMN itself, see What is BPMN?.

What DMN models​

DMN is for the bit of work that isn't about flow — it's about figuring out an answer. It answers questions like:

• "Given this customer's age, income, and credit score, what loan tier do they qualify for?"
• "Given this transaction, is it high-risk?"
• "Given this clinical input, what's the triage priority?"

DMN's primitives are decisions, input data, business knowledge models, and decision services, organised in a Decision Requirements Graph. The logic inside each decision is a boxed expression — usually a decision table.

DMN is stateless. Given the same inputs, a decision always returns the same outputs. There's no concept of waiting, no concurrency, no time progression — just expressions over inputs. That's a feature: it's what makes decisions cheap to evaluate, easy to test, and trivially auditable.

For more on DMN itself, see What is DMN?.

Where they overlap (and don't)​

Some surface-level overlap can confuse newcomers, so it's worth being explicit:

Both use FEEL. FEEL is the expression language defined inside the DMN spec, but it's used inside BPMN too — for sequence flow conditions, script tasks, and I/O mappings. One language across both surfaces is a significant ergonomic win when you have it. in QuantumBPM, FEEL is the script language for BPMN as well as the expression language for DMN. You can try it in the browser at the FEEL playground.

Both can express conditional logic. You can model if age < 18 reject, else approve as a chain of BPMN exclusive gateways. You can also model a long-running multi-step approval flow inside a single DMN function.
Both are bad ideas. BPMN gateways are the wrong level of abstraction for evaluating a rule set. DMN has no concept of waiting or human tasks. Use each for what it's designed for.

Neither is the other's parent. DMN is sometimes described as "a part of BPMN" — it isn't. They're separate specifications, governed independently, and DMN is genuinely useful even with no BPMN anywhere in the picture. A pure decision API (no process around it) is a perfectly common DMN use case.

How they work together​

The integration point in the BPMN spec is the business-rule task. It's a task that delegates to a decision engine, passes in the current process variables, and writes the decision's output back into the process state. The pattern looks like this:

[Start] → [Service task: fetch customer]
       → [Business-rule task: "Loan Approval"]   ← calls DMN
       → [Exclusive gateway: approved?]
            ├─ yes → [Service task: disburse funds] → [End]
            └─ no  → [User task: notify customer]   → [End]

The DMN side is just a decision (or a small DRG) named Loan Approval with inputs like age, income, creditScore and an output { approved: boolean, tier: string }. The BPMN side handles everything else: pulling data, branching, waiting, escalating, retrying, recording.

In QuantumBPM, the business-rule task invokes registered DMN definitions in-process, so there's no external decision-service round-trip — the BPMN engine and the DMN engine live in the same product and share the same project, identity, and audit history. See the BPMN overview and DMN overview for the supported feature surface on each side.

A heuristic: which one do I need?​

When you're sketching a new system, ask:

1. Does this thing run over time, with multiple steps that have to happen in some order? → BPMN.
2. Does this thing involve waiting — for a human, for an external system, for a timer? → BPMN.
3. Does this thing need to survive crashes, restarts, and resume mid-flight? → BPMN.
4. Does this thing take inputs and return an answer, with no waiting and no side effects? → DMN.
5. Are the rules being changed by non-engineers? → almost always DMN, regardless of where they sit.
6. Does the thing need both — flow and decisions inside the flow? → both, with DMN called from BPMN business-rule tasks.

The mistake is to lean too hard on either side. A pure-BPMN model with twenty exclusive gateways is unreadable. A pure-DMN model that tries to encode "wait for the customer to upload a document" can't. Use the right tool for the right shape of problem.

Where to go from here​

• What is BPMN? — the BPMN primer.
• What is DMN? — the DMN primer.
• BPMN overview and DMN overview — what's supported in QuantumBPM.
• Why QuantumBPM ships both — how a unified BPMN + DMN platform compares to running two stacks.

If you want to model a process that calls a decision end-to-end in a single product, start at the platform overview.

This post is about the bet we made — running BPMN on top of Temporal — what it cost us, what it bought us, and why we think Temporal developers are the audience that benefits the most from a BPMN layer sitting above their existing investment.

The bet​

A BPMN engine is two distinct pieces of software glued together. One half is a durable execution substrate — the code that survives crashes, replays workflow history deterministically, schedules timers across days and weeks, fans out to workers, retries with backoff, and keeps state consistent under concurrent execution. The other half is the BPMN-specific machinery — element semantics, scope hierarchies, compensation handlers, message correlation, the modeler, the operations UI, the replay scrubber, version migration, RBAC, audit history.

Camunda's bet was to build both halves. Camunda 8's Zeebe is a Raft-based event-sourced workflow broker built on top of Atomix — a from-scratch durable execution engine designed specifically for BPMN. It's a defensible bet, but it isn't a free one.

Two consequences of that bet are worth being specific about, because they shaped our thinking.

The substrate is yours forever, including the parts you'd rather not maintain. Zeebe's consensus layer is a Java fork of the original Atomix. Upstream Atomix moved to Go some years ago and is now an entirely different project — leaving Camunda effectively the maintainer of the Java consensus library underneath their engine. Every layer you build yourself is a layer you maintain yourself, indefinitely. The unglamorous layers (consensus, log replication, storage formats) accumulate maintenance the same way the glamorous ones do.

Decoupling the engine from observability creates structural drift. Camunda 8's runtime is decoupled from Operate, their separate operations product, and synced through Elasticsearch exporters. Those exporters are eventually consistent: events flow from the broker through exporters into Elasticsearch, and Operate reads from Elasticsearch. Operators regularly report Operate falling behind reality, showing stale state, or missing events when the broker has already moved on. That isn't a bug — it's a structural property of an architecture that splits the engine and the operational view into separate products communicating asynchronously.

Our bet was different:

Durable execution is a solved problem. BPMN semantics are not. Build on Temporal and put our engineering effort into the layer where the actual product lives.

Temporal is funded, well-staffed, and runs in production at Uber, Snap, Coinbase, HashiCorp, Stripe, and Datadog among many others. The storage layer, the replay engine, the event sourcing, the SDK story across seven languages — none of that is ours to maintain. Our team gets to spend its time on the BPMN spec, on the modeler, on the operations UI, on simulation, on DMN integration. The layers users actually see.

The shape of the architecture also avoids the observability drift problem. Our operations UI reads BPMN process state by replaying directly from Temporal's workflow history (GetProcessStateFromHistory) — there's no separate exporter pipeline, no Elasticsearch sync, no "the engine says one thing and the UI says another." If Temporal has the event, we have the event. If we don't, neither does Temporal.

That's the bet. The rest of this post is what fell out of it.

What Temporal gives us, for free​

Mapping BPMN concepts onto Temporal primitives turned out to be remarkably clean:

• A BPMN process instance is a Temporal workflow.
• Service tasks, user tasks, script tasks become activities or signal-receiving blocks inside the workflow.
• Messages and signals become Temporal signals.
• Timer events become Temporal timers.
• Call activities become Temporal child workflows.
• Variables live in workflow-local state, replayed deterministically with the workflow.
• Boundary events and event subprocesses are scoped goroutines (workflow.Go) tied to the parent's cancellation context.

Once that mapping clicked, a long list of capabilities came along essentially for free:

• Durable execution. A worker crash mid-process is invisible to the engine. The instance resumes from the next event in its history.
• Long-running is the default. A process instance waiting two weeks for a customer document doesn't pin a database row or a goroutine in any non-obvious way. Temporal sized for one workflow scales to the next million the same way.
• Event-sourced history. Every step is recorded. This is what powers our replay scrubber in the operations UI — given any process instance, we can reconstruct the BPMN-level state at any point in its execution from GetProcessStateFromHistory.
• Polyglot workers. A service task can be implemented as a Temporal activity in any of Temporal's seven SDK languages (Go, Java, Python, TypeScript, .NET, PHP, Ruby), or — for languages without a Temporal SDK, or workers that need to live outside the Temporal pool — as an HTTP poll-based external worker in any language with an HTTP client.
• Standard storage. Postgres, MySQL, or Cassandra — pick one. There is no proprietary log format to operate, no custom storage engine to babysit.

That's the substrate. None of it is novel; Temporal has been doing it well for years. The point is what we don't have to build.

What we had to build on top​

Temporal alone is not a BPMN engine. It is a primitive — a set of building blocks for writing durable workflows in code. Turning it into a BPMN runtime required a non-trivial amount of work:

• 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, standard loops.
• Scope tree and event bubbling. BPMN compensation, escalation, and errors target logical scopes. They traverse the active ancestry chain, not the static graph — so a re-entered subprocess resolves correctly to the currently-live ancestor. A naive Temporal implementation can't handle this; we maintain a deterministic scope hierarchy on every process instance.
• Cancellable scope goroutines. workflow.Go does not inherit cancellation from arbitrary parent contexts — a footgun we hit early. Our BPMNContext derives node-scoped contexts that are cancelled correctly when an interrupting boundary event fires.
• Concurrency-safe state for query handlers. Temporal query handlers run on a separate goroutine from the workflow's main execution and can read workflow state concurrently with mutations from inside the workflow itself. We protect InterpreterState with sync.RWMutex so an in-flight getProcessState query never observes a partially-mutated history slice or scope-tree map. This is what makes our replay scrubber UI safe to poll continuously against a running instance.
• Live instance modification. Insert a token before a node, cancel a token, on a running instance, without restarting the workflow. Exposed via the API today.
• Version migration. Explicit migration plans move in-flight instances to a newer process-definition version. This is the part of Patch/GetVersion that everyone struggles with, made into a first-class operation on a typed graph.
• Replay slider UI. Reconstructs BPMN state at any point in the Temporal history and lets operators scrub through the timeline of an instance.
• Inline DMN integration. Business-rule tasks invoke registered DMN definitions in-process — no external decision-service round-trip. The decision evaluation is recorded in the BPMN execution history alongside the activity that called it.
• External worker queue. A HTTP poll API for service tasks that need to live outside the Temporal worker pool — languages without a Temporal SDK, workers behind a firewall, or teams who prefer the polling model.
• The platform layer. Visual modeler, projects, RBAC, audit history, multi-tenancy, OpenTelemetry, Prometheus metrics — what 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.

What this gives Temporal developers back​

If you're already running Temporal, you are not the audience that needs to be convinced BPMN is "an executable diagram language" — you already write executable workflows. The question is what BPMN gives you that your current setup doesn't.

The honest answer, from our side:

1. A diagram for the things engineers don't own. Temporal Web is a great tool — for engineers. It shows event histories, workflow histories, activity logs. It does not give a product manager, an ops engineer, a compliance officer, or a support rep a way to see what an instance is doing. A BPMN diagram does. The same artefact you ship to engineering becomes the artefact you give to the business.

2. Versioning that operators can reason about. Most Temporal teams have a war story about Patch/GetVersion. Our migration plans turn version bumps into a typed operation on a typed graph: "instances at node X move to node Y in the new version, instances at node A stay where they are, this branch becomes that branch." Still hard, but no longer line-by-line code archaeology.

3. Compensation and saga as a primitive, not a pattern. BPMN compensation handlers have spec-defined semantics that have been sharpened over fifteen years. If you've ever shipped a Temporal saga with a subtly broken compensation order, BPMN's named-error + compensation-handler model is a real upgrade. You can keep your existing Temporal workflows; just model the saga-shaped parts in BPMN and call them as child workflows.

4. Human-in-the-loop without rolling your own. User tasks are a first-class BPMN element with a typed completion API. We hold the token; you build a UI on top via our REST API. No need to invent your own task-list table, claim/release/reassign protocol, or escalation timer wiring.

5. DMN as a primitive your Temporal workflows can call. This is genuinely useful even without adopting BPMN. Define your business rules — pricing tiers, eligibility checks, risk scoring — in a versioned DMN model, and call them from inside an existing Temporal activity using our SDK. You get versioning, audit trails, and the ability for non-engineers to edit the rules without touching your Go workflow code.

6. An operations UI sized for non-engineers. Running instances list, incident resolution, message/signal correlation, token modification, replay scrubbing — all in a UI that doesn't assume the user reads workflow histories for breakfast.

The integration story matters too: a Temporal team running on a self-hosted cluster or on Temporal Cloud doesn't need a second durable execution engine; QuantumBPM is designed to run against the Temporal you already operate.

What this isn't​

To be honest about scope: this isn't an "operations UI for any Temporal workflow you already wrote." Today our scrubber understands BPMN-shaped workflows specifically — the visual reconstruction depends on the BPMN scope tree we maintain. Generalising the replay UI to arbitrary Temporal workflows is on our minds, but it is not what ships today.

What ships today is a BPMN engine that runs as a Temporal application, integrates with the Temporal infrastructure you have, and gives you the BPMN-shaped layer on top. If your problem is shaped like a business process — onboarding, claims, approvals, fulfilment, KYC, case management, anything human-and-system-and-time — that's the right shape to model in BPMN, and Temporal is the right substrate underneath.

Where to start​

If you're a Temporal developer curious about whether the BPMN layer fits your team:

• QuantumBPM comparison — the architectural deep-dive on what we built on top of Temporal.
• BPMN vs. Temporal — the honest decision framework: when raw Temporal is right, when a BPMN engine on top earns its keep.
• BPMN overview — what's supported in the engine.
• Platform overview — quickstart for self-hosting locally with docker-compose.

The BPMN engine is one half of QuantumBPM. The other half is a DMN 1.5 decision engine that runs in the same product and shares the same project, identity, and audit history. The two compose naturally — BPMN's business-rule task calls DMN — and that pairing is, for us, the actual reason BPMN-on-Temporal earns its keep over raw Temporal alone.

If you have feedback, war stories about BPMN, Temporal, or the line between them — we'd genuinely like to hear it. Reach us at support@quantumbpm.com.