Camunda vs Workflow Engine NEO

I chose Workflow Engine NEO and Camunda 8 Self-Managed because they put document approval in different places for a .NET product. Workflow Engine NEO can run inside the product and executes native Schemes in Simple Process Notation. Camunda runs as a separate BPMN platform; a .NET service can connect to it and use C# job workers for service tasks. Its C# SDK remains in Technical Preview in 8.9.

Workflow Engine NEO can also import BPMN, but it converts supported diagrams into Schemes rather than running the original BPMN XML. I wanted to see how these two models describe the same approval and what work remains around each engine.

I use the same route as our Elsa comparison: an employee submits a document, a manager approves or rejects it, and a missed deadline escalates the process to a senior manager. The example ends at escalation.

Here, the manager reviews documents in the product's own UI. I favor Workflow Engine NEO because execution can stay in that product. Camunda supplies Tasklist and Operate, so the team can use ready task and incident views. If the team would otherwise build those screens, they may justify running Camunda and connecting the document service.

I compare Workflow Engine NEO v22 and Camunda 8.9 Self-Managed as they stood on September 24, 2026. I chose Self-Managed because the team must deploy and upgrade both products. With Camunda SaaS, Camunda would run the platform and change that part of the choice. Version 8.9 was the latest released Camunda 8 line on that date. Camunda 7 can embed its Java engine, which makes it a different architectural comparison. At review, Camunda Core was at 8.9.21. Other components had their own versions.

If you are not sure a document approval needs an engine at all, read our post Why Use a Workflow Engine.

What each product includes

Workflow Engine NEO:

Workflow Engine NEO can run inside a .NET application. Workflow Runtime executes native Schemes and stores process state through a persistence provider. You can embed Workflow Designer in the application's UI. Approval Plugin provides Inbox and approval history. Forms Plugin connects form definitions and data to workflow execution. Workflow Engine NEO also has an HTTP API; the product comparison lists the Editions that include these components. It does not ship a separate task or operations portal.

Your application still owns its users, documents, business services, and screens. It can call Workflow Runtime directly or use the HTTP API for workflow operations, without moving the rest of the product behind that API.

Another Optimajet product, Workflow Server, has an admin panel but no task portal. It runs as its own service under its own license. In Workflow Server 10.0.0, the admin panel filters the server's Process Instances by status, such as Error, and can move an instance to another State.

Camunda 8 Self-Managed:

Camunda 8 Self-Managed runs as a separate platform. Its Orchestration Cluster includes Zeebe for execution, Tasklist for user tasks, Operate for inspecting and repairing process instances, and Admin. Business services stay outside the engine and often connect as job workers. You use Modeler tools to author processes. Camunda also offers Connectors for integrations. Camunda's deployment architecture shows the cluster and its supporting services.

Camunda does not replace the document product: your team still owns document data, business integrations, identity configuration, and any custom UI. If Tasklist and Operate fit, the team need not build its own task and incident screens.

Open product diagram at full size

Short answer

The choice is where the approval should live: in your .NET product, or in a separate BPMN platform with its own task and support applications.

Overall recommendation

Workflow Engine NEO:

Use it when the .NET product owns the document screens and permissions. Workflow Runtime can run in its service, and Workflow Designer can embed in its UI. Approval Plugin supplies Inbox items, while Forms Plugin connects forms to the process. Form Engine Designer lets the team style the approval form and adapt its layout to desktop and mobile. It is separately licensed except in the Enterprise Edition of Workflow Engine NEO. The team still builds the task and support screens.

Camunda 8 Self-Managed:

Use it when executable BPMN needs to coordinate services and the team wants supplied applications for users and support. Tasklist displays user tasks and Camunda Forms. Operate lets support inspect and repair process instances. Your product still owns the documents and their permissions, and the team must connect it to and operate the Camunda cluster.

Criteria at a glance

How the workflow models differ

Why it matters

Workflow Engine NEO puts the manager's decisions and the deadline on three Transitions out of ManagerReview. Camunda uses two user tasks, a gateway for the decision, and a boundary timer for the deadline.

Open notation diagram at full size

Workflow Engine NEO:

The approval Scheme starts at DraftActivity, with the business State Draft. The employee's Submit Command moves it to ManagerReview (State Under review), where Approve and Reject trigger separate Transitions to the final Activities. Both decision Transitions are restricted to the Manager Actor, whose Rule matches the user's Identity. A Timer triggers a third Transition to Escalated.

An Activity marks a position in the Scheme, not necessarily a human task. Here, DraftActivity and ManagerReview wait for people, while Approved and Rejected mark the end.

Camunda 8 Self-Managed:

Camunda models Submit document and Manager review as BPMN user tasks. The manager completes the review with a decision value, which an exclusive gateway uses to route to Approved or Rejected. An interrupting boundary timer ends the review task at the deadline and starts the senior-manager route.

For a different integration, the product could send correlated Approve or Reject messages to Camunda. An event-based gateway could wait for the matching message catch event or a timer instead of the Manager review user task shown here. The integration described below keeps that user task.

What the engines execute

Activities and Transitions define the route in Workflow Engine NEO's Scheme. Triggers (Command, Timer, or Auto) and Conditions determine when a Transition can run; Actors, Rules, and Restrictions limit who may take a Command-triggered Transition. Actions perform work. Simple Process Notation has no modeling-only flow symbols: Workflow Designer saves the Scheme, and Workflow Runtime evaluates the routes it shows.

Camunda 8.9's coverage table separates symbols Modeler can draw from those the engine executes. Complex gateways and transaction subprocesses are modelable but not executable; Data Objects and Data Stores are modeling-only. The user tasks, exclusive gateway, and timer used here are supported for execution.

BPMN import in Workflow Engine NEO

The BPMN importer converts supported elements into a Scheme, which Workflow Runtime runs instead of BPMN XML. When importing a Camunda diagram, the team must still review task assignments, forms, worker contracts, and extensions.

One approval process in both engines

Why it matters

The document stays in the .NET product in either design. The route diagram does not show how the manager opens it, how a decision updates the document record, or what support can inspect after a failure. The diagram below shows who owns each job.

Open integration diagram at full size

Workflow Engine NEO:

In the embedded setup shown, the .NET product calls Workflow Runtime directly. If the team runs workflow in a separate service, it can use the HTTP API. Approval Plugin supplies Inbox entries and approval history. Forms Plugin connects form data to the workflow (product comparison).

The application still shows the document, maps signed-in users to workflow Identities, and enforces document permissions. The team supplies a Rule Provider to match the user's Identity to the Manager Actor's Rule, plus Actions that update the document or send notifications. When the manager submits Approve or Reject, the server can select the Command from those available to the user's Identity. A restriction check during execution is optional. Workflow Runtime stores process state through its persistence provider, and TimerManager handles the deadline. The team also builds or adapts a protected support view.

Camunda 8 Self-Managed:

The .NET product creates a draft document, then starts a Camunda instance with its ID. The first BPMN user task is the employee's Submit document, followed by the manager's Manager review. If the team uses Tasklist, both tasks can appear there with Camunda Forms. Operate gives support an incident view. Camunda Forms can use Document preview, but a document ID alone does not make the file available in Tasklist. The product must provide a protected document endpoint and enforce access to it.

The native user tasks do not need job workers. If document updates or service calls are modeled as service tasks, workers or connectors perform them. The team assigns the tasks, enables and configures task authorization, and runs the separate cluster with secondary storage. The employee and manager can also use the product's UI, which retrieves and completes their user tasks through the Orchestration Cluster API.

AI agents in workflows

Why it matters

An agent may recommend approval or choose tools to check a document before the manager decides.

Workflow Engine NEO:

Workflow Engine NEO can treat an agent as a process participant, as in our Elsa comparison. The application represents it with an Identity and maps its response to an available Command. Actors, Rules, and Restrictions filter that list. The host authorizes the agent's request on the server before executing it. An Action can call a model or an application tool; the application supplies the model integration and tool-selection loop.

Camunda 8 Self-Managed:

Camunda 8.9's AI Agent connector has two variants. AI Agent Sub-process resolves tools from activities in an ad-hoc subprocess and handles the feedback loop. The team still implements or connects each tool, defines its inputs, and maps its result. Existing HTTP APIs or MCP tools can use supplied connectors. AI Agent Task can make a single model call; tool calling requires an explicitly modeled loop. Self-Managed also requires LLM provider access and credentials.

In both products:

A workflow history shows which steps ran, not whether the model's recommendation was sound. The product must limit what the agent can read and call, record its recommendation, and decide when a manager must approve an effect. Camunda jobs may be delivered more than once, so worker writes to the document service must be idempotent.

Visual workflow authoring and editor embedding

Why it matters

If customers edit approval routes inside the document product, a read-only diagram does not solve that job.

Workflow Engine NEO:

Workflow Engine NEO's Workflow Designer is a JavaScript component that sits on a page of the document product. It edits the Scheme that Workflow Runtime executes; the supplied Designer API loads and saves Schemes. It also shows running processes interactively, with state updates from the Real-Time Tracking Plugin. The team can change the controls and the activity types customers see on the canvas. The product still authorizes who may open or save each Scheme; a review step before release is something the team must add. Hiding an activity type in the editor does not enforce access rules.

Camunda 8 Self-Managed:

Camunda's Desktop and Web Modeler are separate authoring applications. Web Modeler stores models and provides collaboration, process checks, and deployment. Its iframe sharing shows a diagram inside the document product, but does not let customers edit it there. For editing, the team can embed camunda-bpmn-js, a BPMN editor with Camunda 8 properties.

That editor does not bring Web Modeler's projects, collaboration, process tests, or deployment path. The team must manage BPMN files, authorize edits, and deploy approved models. The bpmn-js license also requires its watermark to remain visible when the editor is embedded.

Human tasks and forms

Why it matters

The manager must find the document, fill in the review form, and submit Approve or Reject. Seeing a button in an Inbox does not by itself authorize the decision.

Workflow Engine NEO:

Workflow Engine NEO's Approval Plugin puts pending Commands in an Inbox by identity. The application maps those identities to users and builds the task screen around its documents. Forms Plugin binds form data and a Command to the workflow; the application displays the form and submits it through the plugin. Forms Plugin is included in all four editions of Workflow Engine NEO. Form Engine Core can render the form under MIT, while Form Engine Designer needs a Form Engine Enterprise license. That license is separate for Workflow Engine NEO Subscription, Business, and SaaS; Workflow Engine NEO Enterprise includes it with OEM rights. See the product comparison and edition terms.

Form Engine's component catalog lists 30+ components across the alternative Material UI, Mantine, and React Suite libraries. Mantine includes multi-select, range sliders, ratings, and date pickers. The licensed Designer lets an author style individual components and set adaptive layouts for desktop and mobile; developers can register custom React components. The team can match the product's design system, but must host and integrate the form UI.

Workflow Engine NEO filters available Commands through Rules and Restrictions. The Forms Plugin submission path checks Restrictions again when it executes the bound Command. With direct ExecuteCommandAsync calls, execution-time rechecking is off by default; the application can enable it explicitly. The Command contract and Rule model explain these checks. The application still owns login and document access.

Camunda 8 Self-Managed:

Camunda's user task has its own assignment and lifecycle. Tasklist provides the queue: users can claim, unassign, and complete tasks, and Tasklist can show Camunda Forms. In 8.9, a linked form must be deployed explicitly; Web Modeler does not deploy it automatically with the diagram. Tasklist does not display an external form reference as a form. A team using its own task screen must integrate that screen with Camunda instead.

Camunda's Form Element Library overview lists 21 elements, among them dynamic lists, tables, file selection, and expression fields; document preview has a separate page. Tasklist renders Camunda Forms with IBM Carbon styling by default. A self-hosted form-js viewer can be styled with CSS, but custom components cannot be imported into Web or Desktop Modeler. To design forms with those components, the team must host its own editor.

With authorization enabled, Camunda 8.9 Tasklist V2 uses PROCESS_DEFINITION or USER_TASK grants to authorize READ, UPDATE, CLAIM, and COMPLETE. Task-level grants can match assignees and candidates, but a sufficient process-level grant bypasses the corresponding task check. Assignment alone is therefore not the access policy; the document service also needs its own permissions. See task authorization.

Form editor examples:

The screenshots show comparable patient-assessment forms, not the document approval in this article. The Form Engine preview shows three medical-history rows and medication tags. The Camunda image shows the form in its editor, not its appearance in Tasklist. The Form Engine captures come from Form Engine Designer.

Form Engine Designer, patient assessment (Form Engine Designer; full-size editor).

Form Engine preview, populated patient assessment (full-size preview).

Camunda Forms editor, patient assessment sample (© Camunda; 8.9 documentation; CC BY-SA; full-size image).

Composition and child workflows

Why it matters

Several document routes may reuse the same review steps. Those steps can become part of each definition, run as a managed child, or belong to an independent process. The choice determines how the team updates and cancels the review.

Open child-workflow diagram at full size

Workflow Engine NEO:

An Inline Activity brings a separately authored Scheme fragment into the parent Scheme at build time. It does not create a child at runtime.

Subprocesses are separate instances in the root's managed process tree, derived from its built Scheme. Fork Transitions control their creation and merging. Combine Inline with these Transitions to reuse the review fragment as a managed Subprocess. Parent-state control normally removes children when the parent leaves their allowed Activities. Basic Plugin can check when all direct children have finished.

CreateProcess starts an independent instance from another Scheme. Store its ProcessId to send Commands or check completion; waiting and joint cancellation must be configured separately.

Camunda 8 Self-Managed:

An embedded subprocess groups steps within the same BPMN definition and instance. Its contents belong to that diagram; it does not expand an external fragment like Inline.

A call activity starts a managed child from a separate BPMN definition and waits for completion. The call can bind to the latest version, the caller's deployment, or a version tag, with variable mappings for data transfer. An interrupting boundary event terminates both the call and its child.

To start an independent process, use the API or a message start event. Coordinate its completion and cancellation with the initiating process explicitly.

Long-running waits

Why it matters

A manager may leave the review untouched for days. The process must remember the pending decision and escalation deadline after a restart.

Workflow Engine NEO:

Workflow Engine NEO stores the current Activity and State, persistent Parameters, and timer registrations in its persistence database. An Idled process uses no waiting thread. If the only application host stops, TimerManager processes overdue timers when it starts again. A waiting process continues from its last committed checkpoint when a Command or Timer arrives.

Suppose the host fails after the document service accepts an update. The Action does not resume at the interrupted instruction. If the process is left Running, recovery follows its configured policy; the application must account for the update that may already have happened.

Camunda 8 Self-Managed:

Camunda keeps the manager's user task and boundary timer in Zeebe's persisted process state. Message subscriptions can hold a wait for a callback in a different process design. For a worker-run service task, Zeebe may reassign the job after its activation timeout while the first worker is still running. A worker that updates the document must tolerate that repeated attempt.

In both products:

The document remains in the .NET product, with its ID in the workflow. No HTTP request or database transaction needs to stay open while the manager decides.

Deadline control, reminders, and escalation

Why it matters

A due date on the manager's task does not send a reminder or stop a late approval. In this example, reminders leave the review open; escalation ends it.

Open deadline diagram at full size

Workflow Engine NEO:

In Workflow Engine NEO, a reminder Timer Transition returns to ManagerReview; the host application implements an Action to send the notification. Re-entering the Activity registers its timers again. Set NotOverrideIfExists on the deadline timer to preserve its original time when the reminder loop runs. A separate Timer Transition moves the process to Escalated. The timer model explains the setting.

Camunda 8 Self-Managed:

Camunda attaches both timers to the Manager review user task. A non-interrupting boundary timer with a timeCycle starts a reminder path while the task remains open; a worker or connector must send the notification. An interrupting boundary timer cancels the task and starts escalation. Its dueDate creates neither route. See timer events.

In both products:

Timer processing can run late. If a decision must be refused at the exact cutoff, add a deadline Condition to Workflow Engine NEO's decision Command Transitions; a worker-backed Camunda completing task listener can deny completion in Tasklist.

Concurrent events and process locking

Why it matters

The manager can submit Approve just as the deadline timer fires. A retry can also send the same document update twice.

Workflow Engine NEO:

Workflow Engine NEO locks the Process Instance through persistence before executing a Command or Timer Transition. The first route changes its Activity; the other route no longer matches. If the timer wins, Approve is no longer valid. If approval wins, the deadline Timer is cleared. Nodes need shared persistence and distinct runtime IDs, and each due Timer has its own claim. See the clustering contract.

The lock also covers Action execution. After a host failure, default recovery sets an instance left Running to Error or Terminated; the team can configure a policy to rerun the Activity or resume after it.

Camunda 8 Self-Managed:

Camunda processes an instance's records in order on one partition. Once the interrupting boundary timer cancels Manager review, a late task completion is rejected; if completion wins, the timer subscription closes. A custom UI must handle that rejection instead of treating a button click as an accepted decision. See internal processing and timer events.

For a service task, Camunda can reassign a job after its activation timeout while the first worker is still running. Both workers may reach the document service; Zeebe accepts one job completion. Reassignment lets processing continue after a worker failure, but the integration must also handle overlapping attempts by live workers.

In both products:

With both Workflow Engine NEO and Camunda, the application must coordinate concurrent updates to the same document, keep document writes consistent with workflow progress, and prevent retries from duplicating external effects.

Scheme versions and live process updates

Why it matters

Next week's approval rule may arrive while a document still waits at ManagerReview.

Workflow Engine NEO:

Workflow Engine NEO keeps each running instance on its stored Scheme version. The team can update an obsolete instance explicitly, or enable lazy updates. In the latter case, an update occurs when the application requests available Commands at an Activity marked IsAutoSchemeUpdate. Publishing a Scheme alone does not move the waiting instances. See Process Versioning.

Camunda 8 Self-Managed:

Camunda creates a new definition version on deployment; existing instances stay on the old one. To migrate this approval, the team maps its active user task to the target definition. Mapping the boundary timer preserves the time already waited; leaving it unmapped restarts the wait if the target still has that timer.

In both products:

The stored model version does not pin application code. An old Workflow Engine NEO instance may call a newly deployed Action; a Camunda job may reach a new worker under the same job type. Test forms, variables, and service contracts against instances still running on the old model.

Administrative changes to running processes

Why it matters

Support may need to return a stuck approval to review or continue after an update already reached the document service.

Workflow Engine NEO:

Direct State Control selects an Activity with the requested business State and IsForSetState enabled. It bypasses incoming Transition checks. By default it runs the target's Actions and automatic transitions; PreventExecution skips both.

The Activity APIs also move directly to an Activity with or without executing it. ResumeAsync evaluates outgoing automatic transitions without rerunning that Activity's Actions. These calls target one Process Instance, including an individual Subprocess. The application secures these calls and supplies any support UI.

Camunda 8 Self-Managed:

Operate lets support inspect and repair BPMN execution. Through instance modification, they can move an element instance, activate or terminate elements, and supply variables. A single request can combine instructions atomically, subject to scope and element restrictions. Activating an element runs its normal behavior, including creating jobs or subscriptions.

In both products:

Both integrations need an audit of who intervened and why, plus any correction to document data or external effects. Model routine rejection and rework as regular workflow routes.

Multitenancy architecture

Why it matters

Logical tenants share storage; physical tenants use separate databases or schemas; hybrid tenancy mixes these placements. Camunda and Workflow Engine NEO implement those boundaries differently.

Open tenant diagram at full size

Workflow Engine NEO:

The HTTP API reads Workflow-Api-Tenant-ID or a configured default and selects a Workflow Runtime and provider. Logical tenants share one database and schema, with records scoped by TenantId. Physical tenants use separate databases or separate schemas in one database. Hybrid tenancy mixes shared and dedicated storage behind one HTTP API.

Tenant-aware operations cover Process Instances and Parameters, Timers and Transition History, Inbox and Approval History. Schemes and Forms can be tenant-specific or shared; tenant reads may fall back to a shared definition. API tenant permissions require optional security configuration. Direct Workflow Runtime calls, custom endpoints, and document data need tenant checks in the host application.

Camunda 8 Self-Managed:

Camunda 8.9's logical tenancy puts tenant IDs on definitions, instances, and jobs in one Orchestration Cluster. They share Zeebe primary state and secondary storage. Tenant checks are off by default in Self-Managed. The team enables them, assigns users, groups, and roles, and configures task and component permissions separately.

Physical tenants in separate databases require separate Camunda deployments, each with its own Zeebe primary state and secondary database. For separate schemas, operators could use separate deployments with secondary RDBMS stores in distinct schemas; Zeebe primary state stays with each deployment. Camunda 8.9 has no tenant-ID routing to a database or schema inside one cluster (RDBMS configuration). A hybrid combines a shared logical cluster with dedicated deployments. The application routes customers between them and protects document access.

Team onboarding and integration

Why it matters

The team must learn the process model and deploy the software that executes it.

Workflow Engine NEO:

The Workflow Engine NEO team learns how Triggers, Conditions, Rules, and Actions affect a Scheme's route. To deploy, it adds Workflow Runtime and a persistence provider to its .NET host, configures Scheme loading, and runs migrations for SQL providers. The host application owns task UI and permissions.

Camunda 8 Self-Managed:

Camunda onboarding covers more than the symbols in this approval. The BPMN 2.0.2 specification lists 15 basic graphical types in five categories before the variants of events, activities, and gateways. Process authors must also know which symbols Camunda 8.9 executes and learn FEEL expressions for conditions and variable mappings. The team deploys an Orchestration Cluster, configures secondary storage for Tasklist and Operate, and connects the document service. That service can stay in C#, although the C# SDK remains in Technical Preview in 8.9.

Operational diagnostics

Why it matters

Support must find the failed step and establish who approved which document version.

Workflow Engine NEO:

By default, Workflow Engine NEO persists Transition History with route, trigger, time, and any actor or executor. Approval Plugin records approval history. Optional Process Logs trace execution but default to in-memory storage; durable logs need a provider. Runtime events notify subscribers without storing history. The Elsa comparison's diagnostics distinguishes these records. The product team decides what its support UI shows and retains.

Camunda 8 Self-Managed:

Operate lets support staff inspect an instance, correct variables, and retry an incident after fixing its cause. A worker job that runs out of retries creates an incident, which Operate displays.

Optimize handles reports and process analysis; Operate handles incidents. Optimize requires Elasticsearch or OpenSearch even when the cluster uses relational secondary storage.

In both products:

For this approval, record the document version, decision, decision maker, delegated authority, and reason outside the diagnostic logs.

Embedding and architectural impact

Why it matters

Self-managed describes who operates the software, not how many services or storage systems it needs.

Workflow Engine NEO:

Workflow Engine NEO runs in the .NET service with a persistence provider. Workflow Designer and the HTTP API are optional integrations. Several runtimes can coordinate through shared persistence; the team owns that database's availability and recovery.

Camunda 8 Self-Managed:

Camunda runs apart from the document product. In 8.9, Zeebe, Operate, Tasklist, and Admin can share one Orchestration Cluster application. Camunda recommends Helm on Kubernetes; Docker on Linux and manual Java deployment are also supported. The Docker Compose quickstart is for development.

Zeebe keeps its execution log and local state in primary storage. Secondary storage serves exported data to queries and user interfaces; 8.9 supports Elasticsearch, OpenSearch, and relational databases for that layer. An RDBMS does not replace Zeebe's primary store. Optimize still requires Elasticsearch or OpenSearch, as the component database matrix shows.

In both products:

Camunda's production plan covers both storage layers, backups, cluster availability, and workers. The Workflow Engine NEO team covers its host, persistence, and the task and support UI built in the product.

Licensing and total cost

Why it matters

Internal approval, public SaaS, and customer redistribution need different license rights.

Workflow Engine NEO:

Workflow Engine NEO has published commercial editions. At this review, pricing lists:

• Business: $10,000 one-time, perpetual, for an internal commercial application.
• Subscription: $8,000 per year for one public web application or SaaS.
• SaaS: $15,000 one-time, perpetual, for one public web application or SaaS.
• Enterprise: quoted terms, including OEM use and redistribution rights.

The SaaS Edition licenses your own application; Optimajet does not host Workflow Engine NEO. All four Editions include multi-server capability and Forms Plugin. The Form Engine Enterprise license covering Form Engine Designer is separate except with the Enterprise Edition of Workflow Engine NEO. BPMN import also depends on Edition.

Perpetual Editions include 365 days of updates; the purchased version keeps working afterward. Later updates and SLA-backed support have separate terms. Source access, where offered, is a time-limited commercial entitlement under the EULA.

Camunda 8 Self-Managed:

Camunda's pricing allows free local development and non-production use. Self-Managed production requires an Enterprise license and a quote. Camunda publishes no production price comparable to Workflow Engine NEO's. Its component licenses differ: Desktop Modeler's MIT license grants no production rights for the engine.

Camunda's OEM program offers terms for embedding orchestration in commercial software. A buyer must price customer deployments, redistribution, usage, and support with Camunda.

In both products:

For this approval, add license, task and form UI work, deployment, upgrades, observability, backups, and support. Workflow Engine NEO uses the document product's UI but needs a support view; Camunda supplies Tasklist and Operate but adds a cluster.

When to choose Workflow Engine NEO

Choose Workflow Engine NEO when approval should stay inside a .NET product.

• Approval in the product's UI. Workflow Runtime runs in its service. Approval Plugin supplies Inbox data and history; the team builds task and support views around the existing document screen and permissions.
• An embeddable process editor. Workflow Designer edits native Schemes inside the product. Form Engine Designer lets the team style the approval form; its license is separate outside the Enterprise Edition of Workflow Engine NEO.
• A native document lifecycle. Simple Process Notation shows Approve, Reject, and escalation as Transitions out of ManagerReview when executable BPMN is not required.
• Mixed tenant storage. Multitenancy routes customers to shared tables, separate schemas, or separate databases behind one HTTP API.

When to choose Camunda 8

Choose Camunda 8 Self-Managed when executable BPMN must coordinate services and the team will use its supplied applications.

• One BPMN process across teams. The user tasks, gateway, and timer in this approval execute in Camunda; job workers connect services. Check execution coverage for other BPMN symbols.
• Shared BPMN authoring. Web Modeler gives process authors a collaborative workspace outside the document product.
• A ready task application. Tasklist presents user tasks and Camunda Forms if managers can work there.
• An operator application. Operate lets support inspect incidents, correct variables, and retry failed work. The team still operates the cluster.

Other products to evaluate

The Elsa comparison also covers Hangfire, Quartz.NET, Wexflow, Workflow Core, Temporal, Durable Functions, and BPMN platforms. The nine-engine roundup compares Camunda 8 with eight others on license, visual designer, and persistence. For other Workflow Engine Family products, the product comparison shows their capabilities and editions. If you are thinking of coding the approval yourself, first read whether building your own engine makes sense.

Test both on your own process

Build the approval and form in both products, then test:

1. Complete each route. Submit, approve, reject, and escalate. Use the same form requirements: document summary, decision, and conditional rejection reason. Compare desktop/mobile layout, styling, validation, document state, task visibility, and decision history.
2. Revoke access. Remove the manager's permission after task creation. Try the UI and a direct workflow call as another tenant; check document access too.
3. Race the deadline. Submit twice near the cutoff, including after it but before timer processing. Retry after a network timeout. Check the winning route and duplicate document updates or notifications.
4. Interrupt execution. Restart the host or cluster during the wait. Then interrupt an Action or any service-task worker after a document update succeeds but before workflow completion. Check recovery and repeated effects.
5. Change a live process. Add a review step while approvals wait. Test old instances, Workflow Engine NEO's optional update on a Command query at a marked Activity, Camunda's explicit migration, and timer, form, and code compatibility.
6. Repair an incident. Diagnose a failed instance, make an authorized repair, restore a backup, and ask another developer to explain the recorded result.

Record code, configuration, UI, deployment, and operations. Count Workflow Engine NEO's task and support views and Camunda's document integration, cluster, and any service-task workers under the same access and availability requirements.

Final recommendation

For this approval inside a .NET document product, I would choose Workflow Engine NEO. Workflow Runtime can run beside the document service, and Form Engine Designer can style the manager's form for the existing UI; the team supplies task and support views. If several teams need one executable BPMN process across services and will use Tasklist and Operate, I would choose Camunda 8 Self-Managed for its supplied task and incident screens, accepting a separate cluster and document integration.