Every six months or so I get a variant of the same call. A COO or operations head has been pitched, in quick succession, by a BPM vendor, an RPA vendor, and a low-code platform. All three demos looked convincing. All three cost approximately the same. All three claim to solve the same problem — “digitize your workflows and eliminate manual rework.”
They do not, in fact, solve the same problem. This post is the decision framework I use with clients to figure out which of the three (or which combination) actually fits a given operational pain point. The frame is simple: what is the shape of the work you are trying to fix, and who is going to own the system once it is live?
What each category was actually built to do
Before the framework, the categories. I am going to describe them the way they behave in practice, not the way the vendor slide deck describes them.
BPM (Business Process Management)
BPM platforms — Camunda, IBM BPM, Pega, Appian in its BPM persona — are at heart orchestration engines for long-running, multi-actor processes. The canonical BPM scenario has a process that spans days or weeks, passes through multiple roles, has clearly defined state transitions (submitted → reviewed → approved → fulfilled), and must be auditable end-to-end.
BPM gives you: explicit process models (usually BPMN), strong SLA and escalation management, human-task orchestration, and traceable audit. What it is weak at: quick UI building, pure system-to-system automation, and anything that feels like a line-of-business app with a lot of screens.
RPA (Robotic Process Automation)
RPA — UiPath, Automation Anywhere, Blue Prism, Power Automate Desktop in its RPA persona — is a surface-automation technology. It drives existing user interfaces: it logs into your legacy portal, clicks through screens, reads data off one system, and types it into another. It is the right answer when the underlying systems refuse to integrate any other way and you need to bridge the gap without rebuilding them.
RPA gives you: fast relief from repetitive swivel-chair work, integration with systems that have no API, and a short payback period for genuinely mechanical tasks. What it is weak at: anything that requires judgement, anything that changes when the target UI changes (which is constantly), and anything that needs to be the system of record. RPA is glue, not structure.
Custom low-code
Low-code platforms — OutSystems, Mendix, Appian in its low-code persona, Retool, Zoho Creator, and the various hyperscaler platforms — are app-building frameworks that compress the time from requirement to working software. They let a small, disciplined team deliver a real line-of-business application — screens, data model, workflow, integrations, mobile — in weeks instead of months.
Low-code gives you: fast delivery of bespoke applications, a reasonable ceiling on complexity before you have to break out full code, and a governance story that IT can live with. What it is weak at: truly heavy processing, extreme UI customization, and situations where a packaged product already exists for your problem. Low-code built in the wrong place becomes the shadow-IT problem it was supposed to replace.
The decision framework
With those definitions anchored, here is the actual framework. I ask four questions in order, and the answers converge on a recommendation.
Question 1 — Does a packaged product already exist for this workflow?
If yes, and the packaged product is within 80% of your need, buy the package and adapt your process. ERP for finance, DMS for controlled documents, CAFM for facility workflows — these are packaged categories for a reason. Do not build in low-code what you can buy as a configured SaaS. The remaining 20% of fit gap is where BPM or low-code might still play, as the glue around the packaged product, not as the product replacement.
Question 2 — Is the work long-running and multi-actor, with state that must be auditable?
If yes, BPM is in the frame. Examples: a bank branch expansion approval that passes through real-estate, compliance, finance, and IT over four weeks. A pharma change control that routes through QA, regulatory, manufacturing, and training across eight weeks. A procurement approval chain with dollar-value-based routing.
The tell is that the work is long enough to outlive a login session, important enough to have SLA obligations, and regulated enough that the audit trail is load-bearing. When all three are true, a BPM engine is the cleanest backbone.
Question 3 — Is the work primarily about moving data between systems that will not integrate?
If yes, RPA is in the frame. The classic case: a legacy insurance platform that only exposes a 1999-era web UI, and an underwriter who spends three hours a day copying fields between it and a modern CRM. RPA handles the copy. Everyone’s life improves. The legacy platform still lives, unharmed.
The tell is that the process itself is fine, but the tooling around it is hostile. RPA is a tactical patch, not a strategic system. I build RPA with a stated expiry — the bot exists until the underlying integration is possible, and then it is retired with ceremony.
Question 4 — Is the work a bespoke line-of-business workflow that no packaged product covers, and does it need screens, forms, mobile, or device integration?
If yes, custom low-code is the right answer. Examples: a multi-outlet retail chain that needs a store-manager checklist with photos, variance notes, and auto-escalation to regional. An O&M contractor that needs a field tech to log work with offline-first capture. A bank rolling out a branch-launch runbook with 140 tasks, 12 teams, and a central dashboard.
The tell is bespoke process + user-facing screens + a reasonable user count (tens to thousands, not millions). Low-code here is faster and cheaper than custom code, and the governance is tractable.
Where the real world disagrees with the framework
The framework is useful but it oversimplifies. In practice the answer is almost always a combination:
- BPM + low-code: the BPM engine owns the long-running state and audit, and a low-code layer delivers the forms, dashboards, and mobile surfaces. This is my default recommendation for regulated, multi-actor workflows with heavy UI needs.
- Low-code + RPA: the low-code app is the system of record, but it needs to read or write to a legacy system with no API. A small RPA bot covers that last-mile integration until the legacy system dies.
- BPM + RPA: the BPM engine orchestrates human tasks, and RPA executes the specific system-interaction tasks that otherwise need a human operator. Common in back-office banking.
What you almost never want is all three as separate platforms owned by different teams. That ends as three tech-debt islands that no one can integrate, each with its own licensing bill.
The governance question
Whichever combination you pick, the governance question dominates the five-year outcome more than the platform choice does. Who owns the models? Who owns the bots? Who reviews the low-code apps before they hit production? Who kills the ones that have become unused? I treat governance as a day-one deliverable, not a year-two afterthought. Platforms do not rot. Ungoverned portfolios of platforms rot.
Where I fit in
I run this framework with operations leaders as part of a system audit engagement — typically three to four weeks to map the actual workflow pain, test each candidate against these four questions, and land on a recommendation that names vendors, scopes, and sequencing. From there, most clients move into a process digitization engagement to build the first workflow, and I stay in an advisory capacity while the internal team builds out the rest.
If you are sitting with three demo decks and a decision to make, let’s talk about it. The worst outcome is picking a platform because the demo was the most convincing. The best outcome is picking the combination that fits the shape of the actual work — and leaving the other two in the “considered and rejected for good reasons” folder.