Robotic Process Automation vs Workflow Automation

Most of what ranks for robotic process automation is either 2018 vintage hype about digital workforces or a vendor page that ends in a demo booking form. Neither tells you the thing that matters operationally: RPA is not a strategy, it is an integration method of last resort, and the organisations drowning in it are the ones that treated it as the default.

The demotion is real and it is correct. It is also not the same thing as death. There are systems in production right now, in banks, insurers, hospitals and logistics firms, where a screen-scraping bot is genuinely the only supported route in. Pretending otherwise is how consultants lose credibility in the first meeting.

This post gives you the decision hierarchy that tells you when to reach for a bot, the honest cost of each rung below it, a vendor table with actual published prices where they exist, and the governance controls that stop an estate of 30 bots becoming an estate of 300 that nobody owns.

What robotic process automation actually is

Robotic process automation is software that operates another application through its user interface, replaying the same clicks, keystrokes and screen reads a human operator would perform. The bot has no privileged access. It sees a window, locates a control by selector or by image, and acts on it.

That is the whole distinction. Workflow automation and iPaaS tools operate on structured payloads: a webhook fires, a JSON object moves, a record is created through a documented endpoint. API integration operates on a contract that the vendor versions and deprecates on a published schedule. RPA operates on pixels and DOM nodes that nobody promised would stay put.

The practical consequence: an API integration breaks when a contract changes, and you usually get advance notice. A bot breaks when someone moves a button, and you get no notice at all. This is the single fact that should drive every RPA decision you make.

The decision hierarchy: four rungs before you reach for a bot

Work down this ladder in order and stop at the first rung that works, because each step down buys you a permanently higher maintenance cost. The ladder is the spine of any sane automation policy, and writing it into your standards document is worth more than any tooling decision you will make this year.

Rung 1: native integration

If the two systems already speak to each other through a vendor-built connector, use it. The vendor owns the breakage. When Salesforce changes an object model, the connector maintainer fixes it and ships an update. Your maintenance cost is reading release notes.

Rung 2: documented public API

You now own the integration logic, but you are building against a contract with versioning and deprecation notices. Maintenance is real but bounded: auth token rotation, rate limit handling, occasional schema migration. Budget a few engineer-hours per integration per year, plus whatever incident response your error handling does not cover.

Rung 3: database or file-level access

Direct reads against a replica, a nightly SFTP drop, a scheduled CSV export. This is uglier because there is no contract at all, only a schema that the vendor can alter in a point release without telling you. It is still deterministic and it is still testable, which puts it well above the next rung.

Watch the licence terms. Some enterprise vendors explicitly forbid direct database access and will void support if they detect it. That is a contractual problem, not a technical one, and it is one of the legitimate reasons teams end up on rung four.

Rung 4: RPA

No API, no data access, no export. You drive the UI. Accept up front that you have created a dependency on a screen layout you do not control, that the vendor has no obligation to preserve, and that will change without warning during a routine patch cycle.

RPA vs workflow automation vs API integration vs custom code

The four approaches differ mainly in what layer they touch and therefore what change breaks them. Cost follows from that: the closer you sit to a contract the vendor maintains, the less you pay in ongoing engineering time.

Dimension	RPA	Workflow automation / iPaaS	Direct API integration	Custom code
Operates on	Application UI: windows, DOM nodes, screen regions	Prebuilt connectors and structured payloads	Documented HTTP or SOAP endpoints	Whatever you choose, including private protocols
Breaks when this changes	Screen layout, selector, locale, screen resolution, login flow	Connector version, platform limits, auth scopes	API contract version, auth scheme, rate limits	Any upstream dependency, including your own
Typical cost shape	High per-bot licence plus continuous repair labour	Per-operation or per-seat subscription, low build cost	Engineer build time, then low steady maintenance	Highest build cost, lowest per-run cost at volume
Who maintains it	A dedicated bot support function, in practice	Ops or RevOps, with vendor owning connectors	Whoever owns the consuming service	Your engineering team, forever
Best fit	Closed legacy systems with no programmatic access	SaaS-to-SaaS glue, approvals, notifications, routing	High-volume or latency-sensitive system-to-system flow	Core differentiating logic, unusual scale, strict SLAs

For most B2B teams the middle two columns cover the overwhelming majority of work. RPA belongs in the first column only, and only when the fourth rung of the hierarchy has been reached honestly.

Where robotic process automation is still the right answer

RPA wins wherever the target system is genuinely closed and the alternative is a human doing the same clicks. These are not edge cases invented to justify a licence, they are common in regulated and long-lived enterprise estates.

• Legacy desktop applications with no API. Thick-client accounting, claims and dispatch systems written before REST existed. The vendor may still exist but has no integration roadmap and no intention of building one.
• Mainframe green-screen terminals. 3270 and 5250 sessions in core banking and insurance. Terminal emulation is one of the few places where UI automation is arguably more stable than the alternatives, because the screen layout is fixed by a decades-old application that nobody is redesigning.
• Regulated systems where integration is contractually forbidden. Some clinical, payments and government platforms permit only the certified client. Direct API or database access voids certification. A bot operating the approved client is the compliant route.
• Third-party portals with no export. Supplier portals, carrier tracking sites, regulatory filing systems and insurer extranets that offer a web login and nothing else. You have no commercial leverage to get an API built.
• Short-lived bridges during a migration. A bot that keeps two systems in sync for the eight months of a cutover is a legitimate use of a disposable tool. Give it an explicit decommission date in the ticket that authorises it.

One case that looks like RPA but is not: an old system that speaks SOAP. A WSDL is an API, and a workflow platform can call it. Before scoping a bot against a legacy application, check whether it exposes a service endpoint. Our walkthrough on connecting to legacy SOAP APIs covers the envelope construction and auth patterns that make this workable.

Attended vs unattended bots, and why it decides your bill

An attended bot runs on a person’s machine while they are logged in and typically starts on their action; an unattended bot runs on a server or VM on a schedule with no human present. That single distinction drives licensing cost more than feature set, vendor choice or bot complexity.

Microsoft publishes the clearest illustration of the gap. Power Automate Premium, which includes attended desktop flows, is listed at 15 US dollars per user per month billed yearly. Power Automate Process, which unlocks unattended desktop flows, is listed at 150 US dollars per bot per month, and the hosted variant with a Microsoft-managed VM at 215 US dollars per bot per month, according to the Power Automate pricing page. That is an order of magnitude for the same automation logic, differing only in whether a human is present.

Worked example, stated assumptions. Suppose you have one process taking 20 minutes per run, running 8 times a day, 250 days a year. That is 667 hours of manual work a year. Run it unattended on a single Power Automate Process bot at the published 150 dollars per month and the licence costs 1,800 dollars a year, plus a Premium seat for the developer at 180 dollars. Ignore build and maintenance for a moment and the licence alone breaks even against roughly 3 dollars per hour of loaded labour cost, which is trivially met. Now add a conservative 40 hours a year of bot repair at a loaded 75 dollars an hour and the total becomes 4,980 dollars. Still fine at 667 hours saved. Halve the volume, double the repair load, and the maths inverts. The repair term, not the licence, is what decides these cases, and it is the term every vendor ROI calculator omits. If you want to model this properly, the inputs are laid out in our automation ROI and TCO benchmarks.

The operational tax on unattended bots is separate from licensing. An unattended bot needs a machine that stays logged in, a credential that never expires interactively, a session that survives Windows updates, and a policy exception so the screen does not lock. Every one of those is a security review.

The RPA vendor landscape as it stands

The market has consolidated and repositioned around AI agents, but the classic platforms are all still shipping. What has changed is the marketing: every vendor now leads with agentic orchestration and mentions RPA further down the page. SS&C Blue Prism, for example, states that both Blue Prism Enterprise and its Next Gen platform continue to receive investment alongside the newer agentic layer in its 2026 platform roadmap.

Platform	Licensing model and published price	Attended / unattended	Learning curve	Honest caveat
UiPath	Basic tier listed from 25 USD per month with capped users and 2 unattended robots; Standard and Enterprise are contact-sales only	Both, with unattended gated by tier	Moderate: visual designer, but Orchestrator concepts take real training	Real cost lands in the quote-only tiers. The published entry price tells you almost nothing about an enterprise bill.
Automation Anywhere	Quote-only. No per-seat list price published; sold as an enterprise agreement	Both	Moderate, cloud-native control room	You cannot budget from public information. Expect a procurement cycle before you know the number.
Microsoft Power Automate Desktop	Fully published: 15 USD per user per month for attended, 150 USD per bot per month unattended, 215 USD hosted	Both, split cleanly by SKU	Lowest of the commercial four, especially for Microsoft-shop teams	Desktop flows are Windows only and the free trial excludes them. Premium connector and Dataverse consumption add up separately.
SS&C Blue Prism	Quote-only, enterprise agreement; roadmap references new burst capacity licensing	Unattended-first heritage, server-centric	Steepest: strong governance model, correspondingly heavy process	Best-in-class control model, but the smallest sensible deployment is still an enterprise programme.
Robot Framework or Playwright scripting	Free and open source, Apache 2.0 and MIT respectively; you pay in engineering time and infrastructure	Whatever you build; unattended is just a scheduler	Requires actual engineers. No citizen-developer path.	No control room, no credential vault, no bot register, no audit trail unless you build them. That absence is where sprawl starts.

UiPath publishes a Basic tier starting at 25 US dollars per month covering a small capped user count and two unattended robots, with Standard and Enterprise both requiring a sales conversation, per its pricing page. Treat published entry prices across this market as marketing artefacts. The number that matters arrives after procurement.

The open-source column deserves a specific warning. Robot Framework with its browser and desktop libraries will do the automation perfectly well. What it will not do is tell you which bots exist, who owns them, or which one silently stopped running in March. If you go this route, budget for building that layer, because you will need it.

Bot sprawl: what 200 undocumented bots actually costs

Bot sprawl is what happens when RPA succeeds locally and is never governed centrally, and it is the failure mode every vendor page omits. The pattern is consistent and it takes about three years to fully develop.

• No owner. The analyst who built the bot moved teams. Nobody knows what it does beyond the fact that a report appears.
• No inventory. The control room lists processes, but nothing maps them to business owners, upstream systems or the reports that consume the output.
• Credentials embedded in bot definitions. A service account password typed into a variable three years ago, now used by nine bots, and nobody can rotate it because nobody knows which nine.
• Silent failures found downstream. The bot throws, the run marks as failed in a console nobody watches, and finance discovers the gap during month-end close.
• Maintenance exceeding the labour saved. Each vendor UI update breaks some fraction of the estate. At sufficient scale a full-time team exists purely to keep bots running, which is precisely the headcount the programme was sold to avoid.

The silent-failure case is the expensive one. A bot that crashes loudly gets fixed. A bot that half-completes, writes partial data and reports success is a data integrity incident that surfaces weeks later. The same detection principles apply here as anywhere else in an automation estate, and they are catalogued in our reference on automation failure modes.

Four controls that prevent it

Put these in before the estate reaches 20 bots, because retrofitting them at 200 is a project rather than a policy.

1. A bot register with named owners. One row per bot, version controlled, reviewed quarterly. A bot with no named human owner gets disabled, not investigated.
2. Centralised credential management. No secret in a bot definition, ever. Bots fetch from a vault at run time. This is the precondition for rotation, and the mechanics carry over directly from our ops guide to rotating API keys.
3. Monitoring that alerts on failure and on absence, not on completion. Success notifications train people to ignore the channel. Alert when a run fails and when a scheduled run does not happen at all.
4. A scheduled review that retires bots. Twice a year, every bot justifies its existence against current run counts. Retirement is the default outcome for anything with no runs in 90 days.

The register does not need a product. A YAML file in the same repository as the bot source, validated in CI, is enough for most estates:

- bot_id: fin-portal-invoice-pull
  purpose: Downloads daily invoice PDFs from the carrier portal
  target_system: AcmeCarrier web portal (no API as of last review)
  business_owner: a.okafor@example.com
  technical_owner: platform-ops@example.com
  mode: unattended
  schedule: "0 6 * * 1-5"
  credential_ref: vault://rpa/acme-carrier/svc-invoice
  downstream_consumers:
    - ap-reconciliation-workflow
  alert_channel: "#ops-rpa-alerts"
  alert_on: [failure, missed_run]
  api_check_last_done: 2026-05-14
  api_check_result: none_published
  review_due: 2026-11-14
  decommission_when: AcmeCarrier ships the announced billing API

Two fields there do the real work. The api_check pair forces someone to re-ask whether rung four is still necessary, which is how bots get retired rather than inherited. The decommission_when field makes every bot conditional by default instead of permanent by default.

Do AI agents replace RPA?

LLM-driven computer use changes how brittle a UI automation is, and changes nothing about whether it is auditable. Both halves of that sentence matter, and most coverage picks one and ignores the other.

What genuinely improves: tolerance of layout drift. A model that reads the screen and reasons about what a button does will often survive a redesign that would have shattered a selector-based bot. Task specification in natural language also lowers the build barrier meaningfully. These are real gains and dismissing them is as lazy as overselling them.

What does not change: the system is probabilistic. The same input can produce different actions on different runs. Cost per run is measured in tokens and inference latency rather than a flat licence, and it scales with volume in a way a bot licence does not. Auditability is harder because the reasoning is not a diagram you can hand to a compliance officer.

A deterministic bot that fails 2 percent of the time fails the same way every time and you can code around it. A probabilistic agent that fails 2 percent of the time fails differently each time, which is a different class of problem entirely.

For a finance or clinical workflow, that difference is not a tuning problem, it is a risk category change. The honest position for 2026: use agents for the classification and extraction steps inside a workflow where a wrong answer is recoverable, and keep deterministic execution for the step that moves money or writes to a system of record. We covered where the current agent frameworks actually sit against production requirements in our reality check on CrewAI for client production.

How to migrate an existing RPA estate onto APIs

Migrate incrementally, ranked by fragility multiplied by business criticality, and never as a big-bang replacement programme. A wholesale RPA-to-API migration fails for the same reason wholesale rewrites fail: you spend a year building before anything improves.

1. Inventory everything first. Pull the process list from the control room, then map each entry to a business owner and a consuming process. Expect the list to be longer than anyone predicted and expect a tail nobody can explain.
2. Score fragility. Use evidence you already have: incidents in the last 12 months, number of distinct UI screens touched, whether the target vendor ships UI changes frequently, and whether the bot depends on image matching rather than stable selectors.
3. Score business criticality. What breaks downstream if this bot silently produces nothing for a week. A bot feeding a regulatory filing scores differently from one refreshing an internal dashboard.
4. Re-check for an API on the top quartile only. Vendors ship APIs. A system that had none in 2022 may well have one now, and this check is where most of the migration value is found.
5. Replace the top of the list, retire the bottom. The high-fragility, high-criticality bots get rebuilt on APIs. The low-criticality, no-recent-runs tail gets switched off. Both actions reduce the estate.
6. Run both in parallel before cutover. Bot and API integration write to separate staging locations for one full business cycle, then diff. UI bots frequently encode undocumented business rules that only surface in that diff.

Verdict by scenario

Pick by what the target system exposes, not by what a vendor calls its product category.

• SaaS-to-SaaS integration in a modern stack: RPA is the wrong tool. Use an iPaaS or workflow platform. If someone proposes a bot here, ask which endpoint they checked.
• Closed legacy desktop or mainframe system, high volume, regulated: RPA is correct. Buy a commercial platform with a real control room and credential vault. This is the case the enterprise licence exists for.
• Microsoft-centric shop, a handful of desktop processes: Power Automate Desktop, attended where possible. The published per-bot unattended price is the number that will decide your scope.
• Engineering team, small number of web portals, no citizen developers: Playwright or Robot Framework scripting in your existing CI. Build the register and alerting on day one, not after the estate grows.
• Migration bridge, known end date: RPA is fine. Write the decommission date into the authorising ticket and put a calendar reminder on it.
• Existing estate over 100 bots with no register: Stop building. Inventory first. You cannot govern or migrate what you cannot list, and the situation is not improving while you add to it.

RPA earned its demotion by being sold as a general automation strategy when it is a specific integration technique for closed systems. Used that way, deliberately, with a register and an exit plan per bot, it is a perfectly reasonable tool. Used as the default, it produces an estate that costs more to maintain than the work it replaced. If you are building out the broader layer above it, our guide to enterprise workflow automation covers where the durable orchestration should sit.

Frequently asked questions