Two surfaces, one product
A BPMN process engine and a DMN decision engine in the same platform — designed, deployed, and operated together.
Process surface
- Full BPMN 2.0 modeler — events, tasks, gateways, subprocesses, compensation, escalation
- Live instance view with a replay slider that scrubs the execution trace
- Resolve incidents and send messages or signals to running instances from the UI
- External worker queue + service tasks in any language
- Temporal-backed deterministic execution under the hood
Decision surface
- Visual decision graph + boxed-expression editors for every DMN 1.5 type
- FEEL editor with full language server: autocomplete, hover, signatures, inline errors
- Evaluation modal — test a decision against ad-hoc inputs without leaving the editor
- Historical simulation — replay a draft over your past executions before promoting
A business-rule task in BPMN calls a DMN decision directly — same FEEL, same project, same audit trail.
What makes it different
Things you get out of the box — not bolted on, not in a separate product.
Built-in execution history
Every decision and every process instance is recorded with full input, output, and state. No custom logging pipeline to wire up.
Replay & simulation
Scrub through BPMN instances with the replay slider. Run a draft decision over your past traffic before promoting it to production.
Live operational controls
Resolve incidents and send messages or signals to running instances from the UI. Token modification and version migration are exposed via API.
One FEEL across both
The same expression language drives decision tables and process variables. Learn FEEL once, use it everywhere.
Native Go, no JVM
Sub-millisecond decisions, a single static binary, and no warm-up time. Fits anywhere your platform already runs.
Integration-first
External workers in any language, a REST API generated from OpenAPI, and a terminal UI for evaluation and inspection.
How it compares to Camunda
A side-by-side on the parts that actually differ.
| Feature | Camunda Platform 8 | QuantumBPM |
|---|---|---|
| Surfaces in one UI | Modeler + Operate + Tasklist + Optimize (4 products) | One product, one UI |
| Runtime | JVM (Zeebe + Operate) | 100% Go, single binary |
| Resource footprint | JVM stack + Elasticsearch (multi-service Helm chart) | Single Go binary + Postgres + Temporal |
| DMN historical simulation | Not built-in | Built-in (replay drafts over past executions) |
| BPMN execution scrubbing | Audit log | Replay slider through the trace |
| Resolve incidents | Operate UI | In-app UI |
| Modify token state | Operate UI | Via API (UI on roadmap) |
| Live instance migration | Operate UI | Via API (UI on roadmap) |
| External workers | Yes | Yes |
| Self-host & SaaS | Yes | Yes |
| DMN spec coverage | Partial DMN 1.3 | Full DMN 1.5, conformance Level 3 |
Where teams use QuantumBPM
Wherever rules and processes live next to each other and need to be auditable, replayable, and changeable without a full release.
Financial services
Underwriting rules, pricing engines, AML triage
Insurance
Eligibility, quote generation, claims routing
Healthcare
Clinical decision support, prior auth, claims adjudication, care pathways
E-commerce & marketplaces
Dynamic pricing, promo eligibility, fraud prevention
Telco & utilities
Tariff selection, plan-migration rules
Back-office automation
Deterministic rules, human approval, system integrations
Integrate from any stack
One OpenAPI spec, four first-party SDKs. Same client shape everywhere — DMN evaluation, BPMN runtime, and external workers under a single library per language.
DMN evaluation
Stored definitions by ID or UUID, ad-hoc XML evaluation, and batch calls — all with typed variables.
BPMN runtime
Resource lifecycle, instance lifecycle, messages and signals, and user-task claim/complete in every SDK.
External job workers
Long-poll runtime that owns lock heartbeats and dispatch — handlers register per task type.
Typed variables
A small Vars wrapper carries DMN contexts, BPMN variables, and worker payloads with one type.
github.com/QuantumBPM/quantum-go-sdkGo SDK docs →client := quantumbpm.NewClient(provider)
// Evaluate a DMN decision
out, _ := client.DMN.Evaluate(ctx, "loan-eligibility", variables.Map{
"applicant": variables.Map{"income": 92000, "creditScore": 720},
})
// Start a BPMN process
inst, _ := client.BPMN.StartProcess(ctx, "claim-intake", variables.Map{
"claimId": "CLM-1042",
})
// Run an external worker
client.NewWorker("notify-customer", handleNotify).
WithConcurrency(8).Start(ctx)
Frequently Asked Questions
Everything you need to know about QuantumBPM.
Is QuantumBPM a Camunda alternative?
Yes. Both run BPMN 2.0 and DMN, and QuantumBPM covers the same ground — modeling, execution, operations — in a single product instead of four. The biggest practical differences are a native Go runtime, built-in historical simulation for DMN, and a replay slider for BPMN execution traces.
Can I use only DMN, or only BPMN?
Yes. The two surfaces share infrastructure but stand on their own. You can ship pure DMN decision services without ever modeling a process, or run BPMN and call out to decisions from your own services.
How does this compare to Temporal or workflow-as-code engines?
QuantumBPM uses Temporal under the hood for deterministic execution, but the modeling layer is BPMN — visual, spec-compliant, and editable by people who don't write Go. Workflow-as-code fits when developers own the whole pipeline; BPMN fits when analysts or operators need to read and change the flow.
Self-hosted, SaaS, or both?
Both. The same product runs as a managed SaaS or on-prem via Docker Compose or Kubernetes. The self-hosted build is single-tenant with stateless OIDC for any identity provider; the SaaS build is multi-tenant with billing built in.
What is FEEL and why do I need to learn it?
FEEL (Friendly Enough Expression Language) is the standard expression language defined by the DMN spec — small, readable, and built for non-developers. The same FEEL drives decision tables and BPMN process variables, so you only learn it once. Try it in our online FEEL playground.
What's the migration story from Camunda 7/8?
Our parser matches BPMN and DMN elements by local name and ignores XML namespaces, so most Camunda diagrams parse straight into the model — standard events, tasks, gateways, and subprocesses work as-is. The real gap is runtime semantics: Camunda-specific extensions (forms, custom listeners, Camunda Connect, Zeebe job-worker headers) aren't interpreted, so anything that relies on them needs its equivalent wired up in QuantumBPM.
How does QuantumBPM's DMN compliance compare to Camunda?
The DMN community maintains an open Technology Compatibility Kit (TCK) — a corpus of 3,391 conformance tests against the official spec. As of mid-2024, Camunda Platform 7.21 passes 2,741 (80.8%) and Camunda's DMN-Scala 1.9 passes 2,850 (84.0%). QuantumBPM passes 99.32% (3,367 of 3,390). The TCK is community-run and historically Java-skewed, so we don't lead with it in marketing — but if you're evaluating engines on spec coverage the gap is real.
Try QuantumBPM in 10 minutes
Spin up the whole platform locally with one docker run, or sign up for the managed SaaS.