What is RPA - Robotic Process Automation?

Every definition of RPA describes the same narrow tool

Definition of RPA. Robotic process automation is software that drives other software the way a person would, through the user interface, along rules written down before it ran. In simple terms, a script with a login. IBM calls it "software robotics" doing "repetitive office tasks of human workers, such as extracting data, filling in forms, moving files and more". AIIM is blunter about the edges: work that is "manual, rule-based, and repetitive", needing structured data, coping badly with exceptions.

The one standards body that touched the terminology went a different way. IEEE Std 2755-2017 is an active standard from 28 September 2017, written to bring "clarity and consistency in the use of Software Based Intelligent Process Automation (SBIPA) terminology". SBIPA, not RPA. IEEE made RPA one member of a family that also holds AI, cognitive computing and machine learning. Its full text is paywalled, so the RPA definition everyone repeats, about "a preconfigured software instance that uses business rules and predefined activity choreography", appears here as the academic literature attributes it rather than as something we read in the standard. The neighboring definition of intelligent process automation can be checked directly, quoted verbatim with a page citation.

Then there is the vocabulary gap, which is the real tell. Gartner's glossary calls RPA "a productivity tool" running "scripts" that "activate specific keystrokes in an automated fashion", and the glossary page sits behind a bot check, so that wording comes from search listings rather than a rendered page. Every vendor selling the same product calls it a digital workforce. Between them, IBM, AIIM and UiPath publish roughly seven thousand words defining RPA without a single verifiable, dated, sourced number about what it delivered. The rest of this article is mostly numbers.

What RPA stands for is settled; what it means is not

RPA in technology. RPA stands for robotic process automation, and the first word is the problem. The RPA meaning most vendors publish and the one the standards bodies use are not the same thing. There is no robot. There is a process running on a Windows machine, holding a set of credentials, sending synthetic clicks into applications that have no idea nobody is there. IEEE avoided the word. IBM's own alternate is software robotics, SS&C sells "digital workers", Gartner says scripts. The technical line that matters is IBM's: "The critical difference is that RPA is process-driven, whereas AI is data-driven." A bot follows a path someone drew. A model infers one from examples. That is also where deterministic workflows beat agents and where they lose.

RPA in business. What a company buys is throughput on work that already exists, without touching the systems that work runs through. So what RPA can do stays narrow: high volume, clear rules, structured input, few exceptions. Keying invoices. Moving records between two systems that will never get an API. Onboarding paperwork. Report assembly. The catch is the one EY wrote down in 2016 and buyers still meet the hard way: "a robot only works on sub-processes and hence leaves a lot of the process that a robot cannot handle, and therefore limits savings achievable." Automate 60% of a task and the human still opens the case.

So choosing the process deserves more budget than it gets. A systematic literature review from the University of Ottawa opens by noting that "it is usually difficult to determine what processes and steps to automate, especially with RPA", then finds the tooling still short of the job. The useful split, as Celonis frames it, is that process mining reads event logs out of your ERP while task mining captures what people do on screen, and RPA candidates live in the second layer. Picking them off a workshop whiteboard means picking from memory, which is where automation programs go wrong before any code exists.

How robotic process automation works comes down to selectors, not intelligence

Key components of RPA technology. Four parts, once you strip a platform down: a designer where somebody records or draws the steps, a robot that is a runtime process on a machine, an orchestrator that schedules jobs and writes the audit log, and a credential store, because a bot logging into six systems needs six passwords it must not contain.

The robot comes in two shapes and the difference is architectural. UiPath's documentation describes attended robots as ones that "act as personal assistants for end-users such as HR personnel or Call Center operators", running inside the user's own session. Unattended robots "are autonomous robots that don't require human supervision to execute jobs", running as a service for batch work, and they "should run under robot accounts, special accounts dedicated to applications or virtual machines, not persons".

The credential store is the piece first projects skip. UiPath supports sixteen store types, from its own database through CyberArk, Azure Key Vault and AWS Secrets Manager, and is explicit that a store is "only required for unattended robots"; Automation Anywhere states the principle in one line, "only the credential references are present in the bots, and not the credentials". Skipping it has a documented cost: a second GSA audit, published 6 August 2024, found the agency "did not establish an access removal process for decommissioned bots, resulting in prolonged, unnecessary access". Retired bots whose logins still worked.

Process flow of robotic process automation. The mechanism worth understanding is how a bot finds the button, and it is not pixels. Microsoft's UI elements documentation, updated 14 May 2026, says desktop flows "use UI elements to interact with applications and webpages, so they don't need to use image recognition or absolute coordinates", and that all of those elements "consist of one or more selectors that pinpoint the UI or web component". A selector encodes the path down the accessibility tree to one control.

A run goes like this. A trigger fires, the robot pulls its credentials by reference, and it walks the selector at each step. Where one fails, Power Automate "uses the following selector in the defined order" from a fallback chain the developer built. Anything the rules do not cover becomes a human exception.

The fragility is in the vendors' own words rather than a critic's. Microsoft writes that "the selector of a UI element is dynamic, meaning that it can be slightly different every time the window or webpage is loaded", which "may cause a UI/browser automation action to fail during running time", and recommends text-based selectors because they are "more reliable and resilient to possible future changes". UiPath's answer is an AI feature aimed squarely at its own core mechanism: the semantic selectors documentation lists the causes of automation failure as "Minor UI layout or theme updates; Dynamic element IDs; Label or class name changes", then promises to fix them by "interpreting intent instead of syntax". A vendor shipping machine learning to survive a theme update is telling you exactly how tightly a classic bot is coupled to a screen it does not own.

One constraint shapes everything downstream: capacity is physical. Microsoft's pricing page states that "a bot can execute one unattended desktop flow run at a time" and that "multiple bots are required to execute concurrent desktop flow runs". A bot is not a service you scale with a slider.

The benefits of robotic process automation are real and routinely unmeasured

Most hours-saved figures in circulation, in vendor case studies and annual reports alike, were never measured. Somebody estimated them before the bot ran and nobody went back afterwards. That is the uncomfortable part of any claim about the benefits of RPA automation.

We know that because one agency's numbers got audited. On 30 November 2023 the Office of Inspector General at the US General Services Administration (GSA) reported that "GSA's assertion in its Fiscal Year 2020 Agency Financial Report that its RPA program reclaimed more than 240,000 work hours annually was inaccurate and unreliable." The method was the problem: "GSA is not verifying the actual work hours saved with end-users of its bots. Instead, the savings that GSA reports in the AFR are based on estimates that are created by the bot owners."

Increased efficiency. Those estimates were made of arithmetic. One bot's claim of 7,500 hours a year came out of 50 staff times 3 hours a week times 50 weeks. Nobody timed anyone. So the auditors sampled the ten highest-claiming bots, 107,242 hours or 44.7% of the total claim, and asked the people using them. "We found that the actual results varied from the estimates for 9 of the 10 bots we sampled." A leasing document bot credited with 3,650 hours: users "consistently responded" that it "did not save any time". Two bots credited with 15,000 annual hours between them "were retired after 4 months". A project closeout bot assumed a 90-minute task where users reported saving about 30 minutes.

Then the finding that belongs on the first slide of every automation business case. GSA's own survey had 80% of bot owners saying the bot met or exceeded expectations, while the same survey showed "74 percent of bots resulted in no cost avoidance". Satisfaction and savings are separate variables.

Cost reduction. Now the other side, because none of this is an argument that RPA does not work. Royal Free London NHS Foundation Trust published a full-year ledger for 2024/25: 45 processes across six departments, more than 437,000 items processed, £711,792 invested including technology and resource costs, £2.46M saved, £1.75M net benefit, equal to 75,630 hours or 62 whole-time-equivalent posts. Note who wrote it. The authors work for the organization that delivered the work, so this is a delivery-side account rather than an independent audit. It is still the only public RPA case we could find that puts the spend next to the return at all.

The scale asymmetry in the same piece is worth as much as the headline. Across nine other NHS clients the same team reports 21 automations saving more than 16,500 hours. Forty-five processes in one trust produced 75,630. Depth in one place beats breadth across many, which is roughly how these programs pay back.

Improved accuracy. Accuracy is usually the vaguest claim on a vendor page, so here is the best published figure that exists. North London Partners Shared Services, running 36 automations across six trusts, reports data accuracy moving from 70% to over 99%, time-to-hire falling from up to 50 days to 16, and £500,000 a year saved on agency staffing. NHS Employers, updated 17 September 2025, adds per-task timings at the same trust: offer letters from 20 minutes to 5, payroll hire from 30 to 10. Each of those is a stopwatch reading on a named task rather than a program-level total, which is what makes them worth chasing.

About that failure rate. Every article on this subject eventually reaches "30 to 50% of RPA projects fail", almost always without a link and almost always without a date. The source is EY's "Get ready for robots", twelve pages whose PDF metadata puts it at November 2016, and the sentence is "we have seen as many as 30 to 50% of initial RPA projects fail." Four things get dropped in the retelling. It is practitioner observation, not a survey, with no sample and no method. It covers initial projects rather than programs. EY adds immediately that "this isn't a reflection of the technology; there are many successful deployments." And EY was one of the largest RPA consultancies at the time, selling the remediation. The same paper argues RPA can "reduce the costs of existing manual operations by 25% to 40% or more". The pessimistic half is the half that got famous.

The freshest survey evidence is not fresh either. Deloitte's seventh Global Intelligent Automation survey, June 2022, 479 executives across 35 countries, found 74% already implementing RPA and 32% average cost reduction among implementers. The number nobody quotes is the payback period: 22 months, up from 16 the year before. No eighth edition appears to exist.

One hole we are not going to fill. There is no citable figure anywhere for what RPA maintenance costs as a share of program effort. Every percentage in circulation traces back to a vendor blog citing another vendor blog, usually one selling an RPA replacement, and they contradict each other. Budget for maintenance and keep a borrowed percentage out of your business case.

Five checks that would have caught the GSA number. Run them before anyone publishes a total.

1. Baseline with a stopwatch, not a workshop. Time the current task with the people who do it, over at least a week. GSA's closeout bot assumed 90 minutes for work that took 30.

2. Ask end users, not bot owners. Survey the people whose day the bot changed, a quarter after go-live. That single step turned a 240,000-hour claim into an audit finding.

3. Track cost per bot. Licence, VM, build hours, and fix hours since. Without that column, saved hours is a number with no denominator.

4. Prorate retirements. Two GSA bots were switched off after four months with their full-year savings still sitting in the total.

5. Separate hours released from money saved. RPA data on hours is not RPA data on cost. Hours become money only when a post closes, a contract shrinks, or freed capacity absorbs growth you would otherwise hire for. Conflating the two is how 80% satisfaction sits next to 74% no cost avoidance.

That last distinction travels well beyond RPA, and it is the most common reason automation programs get quietly canceled in year two.

The RPA solutions on the market split by where the control plane lives

Local RPA solutions. "Can we run it on our own infrastructure" decides most regulated purchases, and the search results answer it badly. The honest answer is a three-way split, and all of it is documented.

UiPath has the strongest local story. Automation Suite's deployment architecture documents an offline mode outright: "A completely isolated setup without access to the internet. This kind of setup requires the installation of an additional registry to store all the UiPath products' container images and binaries, which are shipped in the form of tarball." That is a genuine air gap, on Linux, EKS, AKS or OpenShift, with a multi-node high-availability option. Standalone Orchestrator on Windows and IIS is the lighter path for teams who do not want Kubernetes.

SS&C Blue Prism sells the hybrid shape. Next Generation, launched March 2024, keeps execution local and management remote: "Self-hosted digital workers can be deployed on an organization's network, so no sensitive data leaves its site", with a cloud Control Center over the top. Automation Anywhere ships cloud and on-premises from one codebase, with Control Room and Bot Agent on customer infrastructure in the local model.

Power Automate is the one to be clear-eyed about, because it is often the default. There is no on-premises control plane. Desktop flows execute locally and attended runs work on a personal account, but orchestration, sharing, Dataverse storage and unattended running are cloud-side only. The bridge is the on-premises data gateway, "a locally installed Windows client application that acts as a bridge between your local on-premises data sources and services in the Microsoft cloud", which needs no inbound ports but caps writes at 2 MB and compressed responses at 8 MB. Fine for most work. Not a control plane inside your network.

Leading robotic process automation platforms. The RPA platforms worth shortlisting have not changed much, and the category still has its own Gartner Magic Quadrant, which surprises people who assumed it had been folded into an agentic-automation report. The current citation reads "Gartner, Magic Quadrant for Robotic Process Automation, Arthur Villa | Melanie Alexander | Saikat Ray | Sachin Joshi | Adam Briggs, June 24, 2026." The 2025 edition evaluated thirteen vendors, with Appian, IBM, Microsoft, Pegasystems, Salesforce, SAP and ServiceNow alongside the three usual names. Forrester has moved on: its last RPA software Wave is from Q1 2023.

The arithmetic across those rows is the useful part. A Power Automate unattended bot is $1,800 a year at list. A Blue Prism Enterprise digital worker, on the only public price point that exists for it, is about $14,950. Roughly an eightfold spread for something a marketing page describes with the same three words, which is why the build-versus-buy question deserves an actual spreadsheet.

The $15 to $150 step from attended to unattended is the clearest published illustration of RPA economics anywhere. Attended is a seat: a person triggers it, it runs in their session, it is priced like software. Unattended is a machine: it runs alone, holds its own credentials, executes one flow at a time, and is priced like a contractor. Any evaluation of RPA automation software that skips this distinction produces a budget wrong by an order of magnitude.

On the open-source end, one correction and one caveat. TagUI still appears on every shortlist of free robotic process automation tools, and its last release was version 6.110.0 in June 2022. Do not start there. What is alive is rpaframework, Apache-2.0, version 33.0.1 released 23 August 2026, on top of Robot Framework 7.4.2. The caveat is what free tools do not give you: scheduling, work queues, retries, a credential vault, an audit trail you can hand to an auditor. That is what the license fee actually buys. One nightly browser job is a Python script and a cron entry. Forty processes across six departments is an orchestration problem, and the orchestrator is the product.

RPA in 2026 is mature, not dead and not booming

Two loud stories about this category are both wrong, and the filings settle it. UiPath's Q1 FY2027 8-K, filed 28 May 2026, reports ARR of $1.901B growing 12% year over year, dollar-based net retention of 109%, and $28M of GAAP operating income; the previous quarter's filing recorded the first full year of GAAP profitability in the company's history. That is not a dying category. It is not a booming one either: Gartner's growth series, reported at the time, ran 31% in 2021 against a 19.5% forecast for 2022, and its 2024 market-share analysis is reported at 14.5%. Growth decelerating while profitability improves. That is what maturity looks like on a chart.

For a sense of how unreliable the surrounding numbers are, compare the market sizings. Grand View Research puts the RPA market at $3.79B in 2024. Precedence Research puts it at $28.31B in 2025. They are describing the same industry. Any robotic process automation strategy resting on a single market-size figure is resting on a coin flip.

The real technical shift is that computer use shipped as a general capability at the frontier labs, so a model can now drive an interface with no selector at all. Microsoft's framing of the boundary, in its Copilot Studio documentation, is that because the tool is AI-powered "it adapts to interface changes. For example, when buttons or screens change, the tool continues working without breaking your flow." The guidance is not to throw anything out: keep deterministic RPA on stable interfaces, add adaptive agents where it breaks. Gartner's Magic Quadrant, as quoted by UiPath, predicts that "by 2027, 60% of RPA vendors will include 'computer use' capabilities in their automation platforms to augment UI interactions". Robotic process automation and machine learning are converging in the runtime rather than competing for it.

Which makes the last observation the one to keep. Gartner's June 2025 release on agentic AI, predicting that over 40% of agentic AI projects will be canceled by the end of 2027, defines "agent washing" as the rebranding of existing products and names three of them: AI assistants, chatbots, and robotic process automation. So when a platform tells you its bots became agents, ask what changed in the runtime rather than on the pricing page. Even Pega, which sells into this market, publishes a piece calling RPA a tactical bridge rather than a strategy.

The concrete thing to do this week needs no vendor. Pick the process you are most confident about, sit with the three people who run it, and time it task by task for five working days. Write down what a year of that time costs, and what would actually change on the budget if it disappeared. If the honest answer is that nothing closes and nothing shrinks, you have a satisfaction project rather than a savings project, which is fine as long as you say so before you buy anything. If the numbers hold, you have a baseline that survives an audit, which is more than the federal program in this article had. And if you would rather have someone walk that arithmetic with you before the licenses are signed, that is what the free audit is for.

FAQ