Moxo vs Camunda 8 in 2026: BPMN User Tasks for Staff, Step Types for Outsiders

Overview

A Camunda 8 process is a BPMN 2.0 model another engine can read; a Moxo flow is a template only Moxo runs. The Moxo sources read for this guide, its pricing page and its Description of Services, never mention BPMN or DMN (15 September 2026). Moxo does export, through GET /v1/templates/{id}/export and GET /v1/flows/{id}/export, but a template comes out as "a .moxo.json file" and a flow as a ZIP, so what comes out is a backup rather than a model a second engine could run. Camunda runs that model on Zeebe and routes human steps to a task list built for named users in your identity provider. The access rules of that task list are changing: "In Tasklist V2, candidate users and candidate groups are not evaluated by Tasklist for task visibility or assignment" (docs.camunda.io, read 21 September 2026). Moxo builds from a catalogue of step types and routes work to people who will never appear in that directory.

Six sections follow. Five are scored rounds, which Moxo takes three to two with one knockout apiece; the sixth, on what "external" means, is left unscored. Camunda facts come from its documentation, pricing page and about page, read 21 to 23 September 2026; Moxo's from its published documents, its API reference and synthetic AutomationAtlas builder tests on 14 and 15 September 2026.

Company Snapshot

The Core Trade-Off: Can You Take the Model With You? Only With Camunda

Camunda takes this round, and Moxo has no version of what it wins. A Camunda user task is an element of a BPMN 2.0 model rather than a setting inside a product, so the diagram your engineers draw outlives the engine that ran it. Moxo exports too, a template as "a .moxo.json file" and a flow as a ZIP, but those are backups rather than models a second engine could run, and none of Moxo's pages read for this guide names a notation (developers.moxo.com, read 23 September 2026). Both products will hand you a file; only one hands you something another engine can execute.

Moxo does well inside its own walls. Templates keep a published version history, and a previous version can be restored over the current draft, so a bad edit is recoverable without an engineer. Portability also has a price that Moxo does not charge. Camunda assigns work through assignee, candidateUsers or candidateGroups, states that "For Tasklist to claim the task for a known Tasklist user, the value of the assignee must be the user's unique identifier", and warns that "Usernames and group IDs in the Orchestration Cluster are case-sensitive", so [email protected] and [email protected] are two different people. Moxo starts where that provisioning stops.

Moxo still does not suit a process your own engineers must own end to end. Branching, loops, triggers and scheduled flows are listed from Scale, a custom quote, with only Team carrying a published price and no free plan at all (moxo.com/pricing, 15 September 2026). Camunda asks for a developer and a licence in return: production on your own infrastructure "Requires an Enterprise license", and the free Development tier excludes production use.

With Human Review On, Can an AI Step Ship Without a Named Reviewer? Not on Moxo

Moxo wins this round, because once human review is switched on for an AI step, it will not let that step ship without a person named to check it. In a synthetic test on 15 September 2026, switching on an AI step's "Human review" added a required "Who reviews" picker, and the builder's caption spelled out the rule: "a flow can't be published with human review on but no one assigned." Each human-action step can also carry up to three assistive slots "each fillable by a person or an AI agent", and the home view gathers "AI-review items" alongside overdue and stalled work (Description of Services). The rejection path is decided before publish as well, with four routes on the Approval step, including "Let the approver decide". You get less notation and more opinion, and here the opinion is the right one.

Camunda's user task is the more powerful engineered element. Camunda defines it as work "that needs to be done by a human and is assisted by a workflow engine or software application", carrying dueDate and followUpDate as ISO 8601 values or FEEL expressions, with user task listeners that fire on its lifecycle events (docs.camunda.io, read 21 September 2026). An engineer can build any review gate with that. No Camunda page read for this guide documents a deploy-time refusal for an AI step with nobody assigned to review it, so on Camunda the gate is only as good as the engineer who remembered to build it.

Three of the eight platforms in Automation Atlas's human-in-the-loop ranking ship a wait-for-human step the engine treats as a first-class element: Camunda 8's BPMN user task, Moxo's Approval step and Pega's Approve/Reject step. The other five score lower on how the human enters the path (scored 22 September 2026).

What "External" Means in Each Product

We do not score this one, because the two products are not answering the same question. Search Camunda's documentation for external participants and you find infrastructure. In Camunda 7 the manual explains that "external (service) tasks work in a way that the process engine publishes a unit of work to a worker to fetch and complete", and in Camunda 8 a job worker is "A Zeebe Client that polls for and executes available jobs" (both read 21 September 2026). An external task is a machine, not a client.

The one documented route for a person outside the organisation is the Tasklist public start form. Camunda says "Tasklist hosts the form on a URL that is accessible to all users, eliminating the need for authentication", and that this is useful "when you want to expose processes to users outside your organization, as it allows anyone to start a process". The verb is start. No page read for this guide documents an unauthenticated outsider completing a user task later in the same process, and the route itself is narrowing: "Public start forms are not available when using Tasklist V2 mode."

In Moxo the outsider is a participant for the life of the case: a user record of kind external, never given a login, who reaches an assigned task through a time-limited Magic Link. A link shows that someone opened an inbox, not who they are, and our synthetic tests logged exactly that, with the actor on those rows reading "Public link".

Who Picks From a Shared Queue? Moxo, Once Tasklist V2 Stops Asking

The shared queue is Moxo's knockout, because Camunda's own task list is stepping away from it. Under Tasklist V2, "candidate users and candidate groups are not evaluated by Tasklist for task visibility or assignment", and V2 "relies on authorization-based access control at the process-definition level only" (docs.camunda.io, read 21 September 2026). A design in which any member of a named group may claim a sign-off therefore behaves differently under V2 than under the mode it was modelled for.

Moxo keeps the pattern V2 withdraws. A desk is "a shared inbox that multiple users can pick work from", and when a template binds a role to a desk, every step for that role lands in the desk's queue. The role can even pick its desk from a field value: a desk's routingKey is matched "case-insensitively, never fuzzily", so a flow whose routing field reads "US Bank" goes to the desk that answers to it. Group steps then complete on any one, all or a majority. For a team of reviewers sharing client work, that is the queue working as designed rather than a line in a migration guide.

Camunda does well where the old model still applies. Tasklist V1 evaluates candidate groups, and a custom task application built on Camunda's APIs can read them however you choose, which a platform team with front-end capacity will not mind.

Can a Fix Reach Cases Already Running? Camunda, by Knockout

Camunda wins this round by knockout. Because a Camunda model is a deployable artefact, it can be changed underneath work that is already running: Camunda migrates active process instances onto a corrected definition, and for Camunda user tasks "a migrated active user task remains assigned to the same user if no implementation migration occurs". A correction reaches the cases already open, and the person holding one keeps it. Over a six-week client onboarding, that is the difference between fixing a mistake and waiting for it to age out.

Moxo goes the other way. Its administrative changes land "without affecting in-flight Flows", which is prudence when you are withdrawing a step type and a limit when you are fixing one. On open cases the remedy is a manager reopening, skipping or reassigning steps, one flow at a time. Moxo's upside is that it has no cutover to plan.

Plan Camunda's cutover properly, because the guarantee has one written exception, and it is the migration Camunda itself is steering customers towards. Job worker-based user tasks are deprecated and unsupported in Tasklist V2, and when you migrate one to a Camunda user task, "The current assignee is not preserved. The task is assigned to the initial assignee defined in the target user task definition." (docs.camunda.io, read 23 September 2026). Every approval still open on an older model goes back to whoever the new definition names first, and embedded forms do not survive the move. Drain the queue first, or export who held which task and reassign after. If you are starting fresh, model every human step as a Camunda user task from the first diagram, and the guarantee holds from day one.

Pricing (as of September 2026)

Moxo (from moxo.com/pricing)

Team costs "$5,000/yr" with "100 flows/yr · $100 of AI/yr · Unlimited seats", and since the monthly option was withdrawn that is the only way to buy it: read 22 September 2026, the page shows no monthly figure, the billing toggle survives in the markup but is disabled, and every plan's button reads "Book a demo". The header also links "Request free trial", a trial Moxo's team builds around your processes. Scale is a "Custom quote" with "500 flows/yr · $500 of AI/yr", Enterprise is quoted too, and no free plan is listed.

Camunda 8 (from camunda.com/pricing)

Read 21 September 2026, the page shows three routes and no prices. Development is "Free — build and test on your own machine. No license required.", with the engine, Operate, Tasklist and Optimize marked "Non-production" in its own comparison table. Production on your own infrastructure "Requires an Enterprise license". Camunda SaaS is "Talk to sales to buy, or start with a 30-day free trial."

Cost Comparison

Which Production Price Can You Budget? Only Moxo's

Moxo takes this round narrowly, on the only production price either vendor prints. Team is "$5,000/yr" for 100 flows, which is $50 a flow at the allowance, and a buyer can put that in a budget before anyone books a call. Every Camunda production route goes through sales: SaaS is "Talk to sales to buy, or start with a 30-day free trial", and production on your own infrastructure "Requires an Enterprise license" (camunda.com/pricing, read 21 September 2026).

Camunda wins at trying before buying. Its Development tier is free for non-production work and SaaS comes with a 30-day trial, while Moxo's "Request free trial" is one its team builds around your processes, with no length stated. And a published price is only half a budget: if a flow is not worth $50 in saved effort, the arithmetic argues against Team, and neither page prices the audit trail, which Moxo lists from Scale.

Editor's Note: Nobody asks in a demo what happens to the work already running when you find the mistake. We think Camunda has an answer. Active instances migrate onto a corrected definition, and for Camunda user tasks "a migrated active user task remains assigned to the same user", so the correction reaches cases in flight and the person holding one keeps it. Moxo goes the other way on purpose: an administrator can withdraw a step type "without affecting in-flight Flows". Over a six-week client onboarding, every case opened before the fix finishes on the old design; a manager can reopen, skip or reassign its steps, one flow at a time. Long human processes are where that difference shows. — Rafal Fila, ShadowGen

Selection Framework

Decide how long the work runs and who has to be able to change it mid-course, then pick the engine that assumes those people.

Neither vendor publishes what its audit trail costs. Camunda's user operations audit log arrived in 8.9 with no published price for the licence that carries it, and Moxo lists its audit log from Scale, a custom quote (read 21 and 22 September 2026).