FEEL - the Friendly Enough Expression Language - is what you write inside every DMN decision table cell and, in QuantumBPM, in every BPMN condition and I/O mapping. It is small, but it does not look like the languages most of us came from: equality is =, lists start at 1, function names have spaces in them, and there is no map.

This is the page to keep open while you write it. Every section works on the same sample order, and every section ends with a link that opens it in the FEEL playground with the data already loaded, so you can press Run and change things.

BPMN engines can look intimidating at first. There are process diagrams, several kinds of events and tasks, gateways, variables, integrations, and a whole ecosystem of concepts that make it hard to know where to start.

This article goes back to basics. First, how a BPMN engine actually runs a process. Then, more importantly, what you can build with one: from simple workflows to processes involving data, external systems, and automation.

Let's start with the basics.

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.