You have a business process. It is long-running, it has human steps, it needs an audit trail, and it lives in a Node codebase. Search for how to run BPMN from TypeScript and you get two kinds of answer: a JVM platform, or a diagram renderer that does not execute anything.

There are three real ways to run a BPMN workflow engine from JavaScript or TypeScript, and they differ on one axis that matters more than any other: where you pay for durability.

You have a booking flow that reserves a hotel, then charges a card, then books a flight. The flight step fails. Now what? The hotel is reserved and the card is charged, but there's no trip. You can't ROLLBACK: those were three separate services, three separate transactions, already committed. Someone has to walk the whole thing back: refund the card, release the hotel, and do it in the right order.

That walk-back is the saga pattern, and most teams hand-roll it: a pile of try/catch, a list of "things I've done so far," and a reverse loop that's wrong the first three times you write it. BPMN compensation is the saga pattern as a first-class engine feature: you declare each step's undo action, and the engine handles the reverse-order rollback, the data snapshots, and the recursion for you.

If you've built anything agentic in the last year, you know the shape of it: an agent that plans steps, calls tools, reflects on the result, and loops until it hits a goal. Defined in code - a graph of nodes, a crew of roles, or a hand-rolled loop around an LLM call and a tool list. It works in the demo. Then you try to ship it.

The wall everyone hits is the same one: the agent's autonomy is exactly what makes it ungovernable. What tools is it allowed to call? When does a human get to approve before it does something irreversible? What does the trace look like six weeks later when compliance asks what happened on instance #48213? And what happens to the half-finished run when the worker crashes while the agent is waiting three days for a human to click "approve"?

This post is about answering those questions with a BPMN engine - not by replacing the agent, but by giving it a process to live inside. Where it's useful, we'll be concrete about what QuantumBPM gives you for each piece, because "a BPMN engine could do this" and "here is the endpoint you call" are very different levels of promise.

A question that comes up surprisingly often: "we're picking a workflow tool - should we use Airflow, Prefect, or a BPMN engine?" The fact that it's even a question is interesting, because the three tools are genuinely solving different problems. The confusion comes from the shared word "workflow", which has been overloaded into uselessness.

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.

n8n is a popular open-core (under the Sustainable Use License) workflow automation tool. It's a node-based visual editor with a large library of pre-built integrations, designed for connecting SaaS APIs, automating internal tasks, and replacing the kind of glue code that used to live in cron jobs and shell scripts. Most teams that adopt n8n do so to get something working in a day instead of a sprint - and that's exactly what it's good for.

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.

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.

DMN - Decision Model and Notation - is an OMG standard for describing operational business decisions. It gives you a visual, vendor-neutral way to express the rules that take an input context, apply business logic, and return an answer - and crucially, the model is directly executable. The same diagram a domain expert reviews is the artefact a runtime evaluates.

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.

BPMN - Business Process Model and Notation - is the OMG standard for diagramming business processes. It defines a visual language (rectangles for tasks, diamonds for gateways, circles for events) and an XML serialisation. Modern BPMN engines treat the diagram as something directly executable - the same model a business analyst draws is what the engine runs.

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.

BPMN and DMN are two of the most-cited OMG standards in business automation, and they're often confused. The short version: BPMN models processes over time. DMN models decisions at a point in time. They're complementary, not competitors. Most non-trivial systems end up using both.

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.

When we started designing QuantumBPM's process engine, we ran into the same wall every workflow tool runs into: how do you make execution durable? Survive worker crashes, network partitions, weeks-long timers, replay after restart, exactly-once activity semantics? The honest answer turned out to be: don't build that yourself.

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.