Architecture model Engine-first vs. closed suite Can you swap the UI, or are you locked to the vendor's experience? | Engine + full REST API. Ship whatever UI per business unit; basic tasklist + the Monitoring Tool included as a starting point. | Closed suite — UI, portal, and tooling are the product. Custom frontends are possible but costly. | Authoring surface is Studio/Orchestrator. Custom UIs talk to Orchestrator APIs, but workflows themselves live in the tool. | Power Platform authoring is the experience. Building 'your own front-end' means a separate app with custom connectors. |
Architecture model API-first / bring-your-own UI Coverage and completeness of APIs for building custom frontends | Almost every engine operation is in the API — if you can do it in the engine, there's an API call for it. | REST APIs exist (BAW REST, Case REST, Workflow Center) but don't cover everything the shipped UI can do. | Orchestrator APIs cover runtime well, but authoring is locked to Studio — you can't really replace the author surface. | Flow APIs exist but are secondary; primary experience is the low-code canvas. |
Architecture model Operational control of the engine Can the platform team pull levers on scaling, persistence, and execution? | Full source access. Configure job executor, history, batch ops. Size pods/clusters via IaC per business unit. | Tunables exist but are abstracted; significant behaviors are black-boxed inside the runtime. | Orchestrator config + machine pools; bot-execution internals are opaque. | Microsoft operates the runtime; you get throttling policies, not engine levers. |
Platform Reusable integration assets How a central team delivers connectors / templates to business units | Delegates / connectors + modeler Templates — the direct analog of BAW toolkits. Central team builds; BU devs drop in with variables. | Toolkits model is the canonical pattern; well-understood inside IBM-heavy shops. | Shared libraries / reusable components exist but aren't as central to the model. | Custom connectors + solution packaging; governance via CoE starter kit. |
Platform Per-business-unit isolation Hard boundary between BU workloads — separate DBs, clusters, even infrastructure | Different BUs can run on their own databases / clusters; sized via IaC. Hard isolation by default. | Typically one shared BAW instance with apps per BU — boundaries are logical, not infrastructural. | Multiple tenants work but get operationally heavy at scale. | Environments + DLP policies; separation is tenant-scoped not infrastructure-scoped. |
Platform Multi-tenancy inside a BU instance Department-level separation inside the same cluster | Native multi-tenancy — easy to add departments/teams without new clusters. | App + team model; not true multi-tenant isolation. | Folders / sub-orchestrators; overhead increases quickly. | Environments per team; limits on cross-environment sharing. |
Citizen developer Authoring surface for non-developers Can a business user build or modify a working automation without engineering? | DMN decision tables (spreadsheet-style) plus FEEL — Camunda's "Friendly Enough Expression Language," explicitly designed for analysts — give BAs real authoring power. Element templates let the platform team wrap technical complexity so process designers compose rather than code. Camunda Academy ships a dedicated Business Analyst learning path. | BAW Process Designer is developer-heavy. ODM Decision Center (bundled in Cloud Pak for Business Automation) gives BAs a real decision-authoring surface comparable to DMN. | StudioX is purpose-built for citizen devs — point-and-click activity model. Still expects workflow / activity concepts. | Lowest barrier in the market. Cloud flow canvas + Copilot for natural-language flow creation. |
Citizen developer Governance & guardrails Can a central team contain blast radius without blocking authoring? | Citizen devs compose from platform-shipped delegates and templates; scope is structurally limited to what's been approved. | Governance is possible but heavy; not a citizen-dev posture by default. | Automation Hub + CoE patterns work but require deliberate setup. Default state trends toward wild west. | DLP policies, environments, Power Platform admin center. Strong tooling, easy to misconfigure at first. |
Citizen developer Hand-off path to platform engineering When a citizen-built automation outgrows its author, can engineering take over without a rewrite? | Same BPMN artifact regardless of who's editing. Engineering enriches with custom delegates or async logic; no migration. | Process apps can be promoted, but the authoring tools differ enough to add friction. | StudioX → Studio promotion is often a rewrite. Different paradigms, different artifacts. | Cloud flows accept custom connectors. Heavier customization usually means a separate Power Apps / Azure Functions track. |
Standards & portability BPMN 2.0 process execution Native, standards-compliant process modeling and execution | Full BPMN 2.0 engine (Camunda-7 lineage) — tasks, gateways, events, subprocesses, migrations. | BPMN with IBM-specific extensions. | BPMN-lite via UiPath Process Mining / Apps; workflows are XAML. | Proprietary flow model, not true BPMN 2.0. |
Standards & portability BPMN artifact portability Can your BPMN files leave the vendor? Different question from whether the engine runs BPMN. | Pure BPMN 2.0 XML. Files port to any Camunda-7-lineage engine without rework. Vendor-neutral by construction. | BPDs use IBM-proprietary extensions (coach UIs, IBM event types, SCA integrations). Export to standard BPMN 2.0 strips out most of what makes the process actually work. | Workflows are XAML, not BPMN. Process Mining reads BPMN for analysis only — there is no execution-portable BPMN. | Cloud flows are Microsoft-proprietary JSON. No BPMN export path of any execution value. |
Standards & portability DMN 1.3 decision engine Portable decision tables and FEEL expressions | DMN 1.3 engine with FEEL + decision requirements graphs. | Operational Decision Manager (ODM) — powerful but proprietary. | No native DMN — rules built inline in workflows. | Dataverse business rules — not DMN-compliant. |
Standards & portability Case management (CMMN) Unstructured, knowledge-worker-driven case handling | CMMN 1.1 support — plan items, lifecycles, criteria. | Industry-leading case foundation — gold standard. | Not a case-management tool. | No CMMN. Case management happens in the adjacent Dynamics 365 Customer Service product, not in Power Automate itself. |
Automation style Long-running orchestration Durable, multi-day / multi-system workflows with state | Durable job executor, timer/message/signal events, in-flight migrations. | Core strength — enterprise orchestration. | Orchestrator queues + long-running workflows; less mature. | Approval + flow chaining; best under 30 days. |
Engine capabilities External task pattern (pull workers) Workers poll the engine for work; can run anywhere, in any language | Topic/lock/complete APIs from Camunda 7. Workers can be polyglot and cross-zone. | No direct equivalent — service tasks call engine-resident code. | Orchestrator queues are pull-based, but workers must be UiPath bots. | Push-only flow model; no pull-from-topic pattern. |
Engine capabilities Live in-flight process migration Move running instances between process versions without cancel/restart | Migration Plan API with validation, sync + async-batch execution. | Possible but brittle and manual — teams typically run versions in parallel. | Workflow versions exist; no in-flight migration. | Flow versions exist; no in-flight migration. |
Engine capabilities BPMN compensation handlers Standards-based undo semantics for multi-step, multi-system work | Full BPMN compensation events + handlers; works inside subprocesses and transactions. | Supports the construct but commonly sidestepped in favor of integration-code rollback. | No formal compensation pattern. | No formal compensation pattern. |
Engine capabilities Batch operations at scale Bulk migration, cancel, retry, modify across thousands of instances | Seed/execute/monitor job architecture; monitored via the Monitoring Tool; tunable. | Bulk admin operations exist; less structured at 10K+ instance scale. | Queue-level bulk ops; process-level bulk modification not native. | Bulk resubmit for failed runs in the admin center; no equivalent to process-level batch modification or migration. |
Engine capabilities Job prioritization + incident model Per-job priority values, retry cycles, incidents as first-class entity | Priorities, configurable retry cycles, and first-class incidents all come from Camunda 7. | Retry + error handling; priority model less elegant. | Queue priorities for bots; no formal incident primitive. | Basic retry policies only. No job priorities, no formal incident primitive. |
Engine capabilities Tunable history / audit levels Per-deployment audit volume; decoupled from runtime | NONE → FULL levels; custom history handlers; runtime doesn't read history DB. | Extensive audit; harder to tune per workload. | Orchestrator logs; single level of verbosity. | SaaS-managed run history + Purview overlay. |
Engine capabilities Process unit-testing framework Assert against a BPMN process the way you assert against code | camunda-bpm-assert + JUnit; in-memory engine; real CI-friendly testing. | Unit tests possible but heavy; most teams rely on integration envs. | UiPath Test Suite (separately licensed), focused on robot flows. | No formal unit-testing story; validation is runtime-only. |
Automation style UI / attended RPA bots Screen-scraping and desktop automation of legacy apps | Not an RPA platform — integrate via external tasks or delegates to UiPath / Power Automate. | IBM RPA (separate product) — modest market share. | Market-leading attended + unattended bots. | Power Automate Desktop — broad and capable. |
Automation style API / system-to-system integration REST, SOAP, messaging connectors between back-office systems | REST, SOAP, external tasks, full JVM extensibility. Delegates are first-class integration assets. | Integration Designer + IBM middleware. | Integration Service with 500+ connectors. | 1000+ connectors, deep M365 and Azure coverage. |
Data Control On-prem + cloud parity Can you run the same workload behind the firewall or in cloud? | Run identically on Docker/Kubernetes on-prem or in cloud. Active deployments have used both with no performance delta. | Long history of on-prem; Cloud Pak variant for OpenShift. | Automation Suite on-prem is possible but complex. | SaaS-only core; data gateway only exposes data. |
Commercial Licensing cost model How spend scales with users / bots / processes | Zero license cost; only infrastructure + staff. | High enterprise-license TCO. | Per-bot licensing — scales expensively. | Per-user + per-flow + AI credits — complex. |
Commercial Avoiding vendor lock-in risk Portability of processes, data, skills | Open source — forkable. Camunda-7-compatible lineage = huge existing talent pool. | Proprietary toolbox, IBM middleware dependencies. | XAML workflows non-portable. | Tightly coupled to Microsoft cloud. |
Governance & maturity Underlying engine maturity How battle-tested is the actual code running production workloads? | Fluxnova is new, but the engine is forked from Camunda 7 — ~10 years in production at banks and enterprises worldwide. | Decades of IBM BPM / Lombardi heritage. | Robust RPA core; BPM features still maturing. | Rapid iteration; features less battle-tested than BAW/Camunda. |
Governance & maturity Governance model & community Who actually decides what ships, and on what cadence? | FINOS consortium; large approver list; primary-contributor role rotates across banks (Fidelity through June, then others). Roughly quarterly releases — 2 already shipped this year. | IBM-controlled roadmap; FSI customer base influence but single-vendor. | Single-vendor roadmap; general-purpose focus. | Single-vendor roadmap; general-purpose focus. |
Governance & maturity Financial-services alignment Is the roadmap shaped by financial institutions? | Governed by FINOS; current primary contributors include Fidelity + other large FIs. Zions can be involved in several ways even if we're not a primary contributor. | Long FSI customer base, FSI reference architectures. | FSI vertical, but general-purpose roadmap. | FSI via Cloud for FS; general-purpose roadmap. |