Comparison
Camunda DMN vs ArboRule: a step in a process, or the decision itself.
DMN is a good standard and Camunda implements it properly. The question is whether your decision is a step inside a longer process, or the thing itself.
The short answer
Choose Camunda DMN when
- You already need BPMN. If the decision sits inside a long-running orchestrated process with human tasks, timers and compensation, running both on one engine is a genuine architectural advantage.
- The standard matters to you. Camunda implements DMN 1.3 with decision requirement graphs, business knowledge models and full hit-policy coverage, and the models are portable XML rather than a vendor format.
- Your decisions are self-contained rule tables over data the process has already gathered. That is exactly the shape DMN was designed for, and it executes it very fast.
- You want the decision pinned to the process version that deployed it. A business rule task can bind to the latest version, to the deployment, or to a version tag.
- You need to run it yourself. Self-managed is documented for Kubernetes via Helm, Docker per component and manual JAR installation across the major clouds and OpenShift.
Choose ArboRule when
- The decision needs its own data. In Camunda a DMN decision evaluates variables handed to it; fetching a bureau report means modelling that call as a separate BPMN task first.
- The decision is the unit of work, not a step. Versioning, rollout, history, review and pricing here are all organised around one decision rather than around a process instance.
- You want a decision record kept for years. Camunda's hosted default time-to-live for the orchestration cluster is 30 days, with longer retention on an enterprise plan; ours is five years by default and configurable per workspace.
- A person has to look at some of them. Camunda's user tasks belong to processes; putting a human in the loop means wrapping the decision in a BPMN process around it.
- You would rather not learn two notations. A credit policy expressed as DMN inside BPMN is two models to maintain where the decision was the only thing you wanted.
Side by side
Every row links to where it came from.
Claims about Camunda DMN are taken from Camunda DMN’s own documentation, pricing and repositories — never from a review site, and never from us. Follow the link in the left column to check any of them.
| Criterion | Camunda DMN | ArboRule |
|---|---|---|
| What it iscamunda.com — decision engine read 2026-07-30 | different model DMN 1.3 executed by Zeebe, the same engine that runs BPMN — Camunda markets it as a cloud-native workflow and decision engine. Decisions are a component of a process orchestrator, not a standalone product. | A decision platform. There is no process orchestrator around it; the decision, its version, its trace and its referrals are the unit. |
| Licencecamunda.com — 8.6 licensing update read 2026-07-30 | different model Not straightforwardly open source any more. Camunda 8's repository carries both Apache 2.0 and a Camunda licence, and since 8.6 a single unified licence grants source access but requires a paid production licence for any use beyond development and testing. Camunda 7, which was Apache 2.0, is archived and end-of-life. | Proprietary and hosted. No source access is offered, and we would rather say that than imply an openness we do not have. |
| Pricingcamunda.com/pricing read 2026-07-30 | not in the product Not published. Three tiers are listed with no amounts and no unit; paid tiers say talk to sales. Self-managed is free for development and testing only, plus a 30-day SaaS trial. There is no free production tier. | US$ 500 a month on the Startup plan, including 50,000 decisions across Sandbox and Live. Priced by decision, not by seat. Building and testing is free up to 10,000 decisions a period. |
| Where it runsdocs.camunda.io — self-managed read 2026-07-30 | in the product Both. SaaS, or self-managed via Helm charts on Kubernetes, Docker containers per component, or manual JAR installation, across AWS, Azure, GCP and OpenShift. | Hosted only. There is no self-hosted, on-premises or bring-your-own-cloud option, and no published certification — the controls are an append-only audit log, role-based access, scoped API keys, configurable retention and SSO/SCIM. |
| Authoringdocs.camunda.io — DMN modelling read 2026-07-30 | in the product DMN decision tables, literal expressions and business knowledge models in Desktop or Web Modeler, with FEEL as the expression language — designed, per the docs, to be readable by business professionals and developers alike. In practice authoring runs through the modeller and a cluster deployment. | A visual canvas with 22 node types. Rule, Decision Table, Scorecard and 2D Matrix are grid editors a policy owner can work in; operand fields also accept Python, and the Code node is Python only. |
| Versioning and rollbackdocs.camunda.io — resource deletion read 2026-07-30 | different model Decisions deploy as decision requirement graphs, referenced with a binding of latest, deployment or version tag. Rollback is by deletion — removing the latest version makes the previous one latest again — and Zeebe never reuses a version number, so it is destructive rather than restorable. | A version is DRAFT, PUBLISHED or ARCHIVED. Published versions are immutable — you duplicate to a new draft — and publishing can require an approved review. There is no one-click rollback: you move traffic back. |
| Staged rolloutcamunda.com — blue-green testing read 2026-07-30 | not in the product Not a product feature. Camunda's own blog demonstrates it as a hand-built BPMN pattern, using a FEEL random-number function to set a probability and an expression to choose which decision runs. | Integer traffic weights across published versions, summing to 100, sticky per grouping_id so an application keeps the version it started on. No shadow mode: a challenger serves real traffic or none. |
| Decision historydocs.camunda.io — data retention read 2026-07-30 | in the product Every evaluation creates a decision instance, searchable through the orchestration cluster REST API and marked eventually consistent. Retention is the catch: the hosted default time-to-live is 30 days for the orchestration cluster and 180 for Optimize, with longer retention only on an enterprise plan. Self-managed retention is yours to configure through archiver and Elasticsearch policies. | Every run stores its input, output, the version that produced it and a node-by-node trace, including each external call's URL, status and latency and each model's SHA-256. Queryable at GET /history/api/v1/decisions. Retention is per-workspace, five years by default. |
| External datadocs.camunda.io — business rule tasks read 2026-07-30 | not in the product A DMN decision cannot fetch anything. It evaluates variables already supplied to it; calling an API is a separate BPMN step using the REST connector on a service task, or replacing the rule task with a job worker — at which point it is no longer DMN. | 28 packaged providers, six databases, and any HTTPS/JSON API through a Custom Connection. You bring your own credentials for each: the platform orchestrates the calls, it does not resell the data. |
| Human reviewdocs.camunda.io — user tasks read 2026-07-30 | different model User tasks are BPMN elements routed through Tasklist, and they belong to processes rather than decisions. There is no human step inside a DMN decision; getting a person into the loop means wrapping the decision in a process. | A Manual Review node suspends the decision and puts it in a reviewer queue; Case nodes record work without blocking the run. Case queues carry SLA policies pinned onto each case at creation, with business-hours clocks and escalation rungs. |
| AI and modelsdocs.camunda.io — agentic orchestration read 2026-07-30 | not in the product Not inside a decision. Agentic orchestration and AI connectors are documented at the BPMN and connector layer; nothing describes invoking a model or an LLM from within a DMN decision table or a FEEL expression. | AI and Agent nodes call OpenAI, Anthropic or Google models inside the decision, on your own API key. No key, no AI. ONNX models up to 32 MB, immutable once uploaded and re-verified by SHA-256 at scoring time, executed in-process. One graph input, CPU only. |
A decision that cannot fetch its own data
This is the single most consequential line in the table, and it is easy to skim past because it sounds like a modelling detail.
In Camunda, a DMN decision is evaluated against variables that already exist. The business rule task hands them in and writes the result back out. If the decision needs a credit file, a device signal or a sanctions check, that call is not part of the decision — it is a preceding BPMN service task using the REST connector, or a job worker replacing the rule task entirely, at which point you are no longer running DMN.
So a real credit policy in Camunda is at minimum two models: a BPMN process that gathers, and a DMN decision that concludes. Both are versioned separately. The trace of what happened is spread across both. When the bureau returns something unexpected, the handling of that lives in the process, not in the policy — which means the person who owns the policy cannot see it.
That is not a flaw in DMN. DMN was specified as a decision notation, and keeping I/O out of it is arguably correct design. It is a poor fit for a decision whose difficulty is mostly in the data it needs.
If your policy's hard part is the arithmetic, DMN is a good notation. If the hard part is the four vendors you have to call and what to do when one of them times out, it is the wrong unit.
Thirty days is a short memory
Camunda does persist decision instances and does let you search them through the REST API — that part is solid, and better than several commercial platforms in this comparison manage.
The default retention on the hosted product is 30 days for the orchestration cluster. Longer retention is available on an enterprise plan, and on self-managed it is yours to configure through archiver settings and Elasticsearch lifecycle policies.
For a credit or onboarding decision, thirty days is roughly the window before anyone asks about it. Disputes, regulatory sampling, model reviews and complaints all arrive later than that. It is entirely solvable — an enterprise plan, or an export pipeline you build and own — but it is a piece of work to plan for, not a default to inherit. ArboRule keeps decisions for five years by default, configurable per workspace.
The licence question people get wrong
Camunda is often reached for as the open-source option. That was accurate for Camunda 7, which was Apache 2.0. It is no longer a clean description of Camunda 8.
Since 8.6 a single unified licence replaced the previous ones. It grants source access — including to Operate, which had been closed — but requires a paid production licence for any use outside development and testing. Camunda 7 is archived and end-of-life. The repository carries both an Apache 2.0 file and a Camunda licence file, and reports no repository-level licence at all.
If open source is a hard requirement rather than a preference, that is worth establishing early. Drools remains Apache-2.0 and GoRules' engine is MIT. Camunda 8 is source-available with a commercial production licence, which is a different thing.
Questions
Is Camunda 8 open source?
Source-available rather than open source in the usual sense. Since version 8.6 a unified licence grants source access, including to components that were previously closed, but requires a paid production licence for any use beyond development and testing. Camunda 7, which was genuinely Apache 2.0, is archived and end-of-life.
Can a DMN decision call an API?
No. A DMN decision in Camunda evaluates variables that were already handed to it. Calling an external service is a separate BPMN step — the REST connector on a service task — or a job worker replacing the business rule task, which stops being DMN at that point. Any decision that needs to fetch its own data therefore becomes at least two models.
Is DMN a good fit for credit decisioning?
For the rules themselves, yes — hit policies, decision requirement graphs and portable XML are a good way to express cut-offs and matrices, and they outlive any one vendor. The friction is everything around them: fetching bureau data, referring a case to a person, moving traffic gradually onto a new policy and keeping the record for years are all things you model in BPMN around the decision, or build yourself.
Last verified July 30, 2026 against Camunda DMN’s public documentation. Products change and pages move; if something here is out of date, tell us at hello@arborule.com and we will correct it.