Definition
RPA automates work by driving the screen: logging in, clicking, typing, copying between windows. It exists because many business systems offer no other way to connect, which makes it powerful in exactly the situations where better options are unavailable.
What RPA is actually for
RPA is often described as a robot doing a person's job. A more accurate description: it is a program pretending to be a person, because the system it needs to talk to will only accept input from people.
That framing explains both its value and its reputation. When a twenty-year-old ERP has no API, no export beyond a printed report, and no vendor willing to build one, RPA is the only route that does not involve replacing the system. It genuinely rescues situations that have no other answer.
It also explains the fragility. RPA depends on the screen staying where it was. A vendor update that moves a button, an added confirmation dialog, or a slow-loading page can break an automation that has run flawlessly for a year, and it breaks in a way that requires someone to notice.
RPA vs. API integration
| RPA | API integration | |
|---|---|---|
| Connects through | The user interface | A programmatic interface |
| Breaks when | The screen changes | The contract changes (usually versioned) |
| Speed | Human-paced | Immediate |
| Setup | Fast, no vendor cooperation needed | Requires the system to expose one |
| Runs at scale | Poorly, one session at a time | Well |
| Maintenance | Ongoing and unpredictable | Low and scheduled |
The rule is straightforward: use an API if one exists. Reach for RPA when the system offers no other way in, when a vendor will not or cannot help, or when the process must work now and the proper integration is a longer project. Just enter with your eyes open about maintenance.
Where RPA still earns its place
Legacy systems remain the main case: the accounting package, the industry-specific application, the government portal that only accepts manual submission. Add to that vendor portals with no partner API, short-lived processes where building a proper integration cannot be justified, and migration work where a bot moves data once and is then retired.
The pattern worth avoiding is RPA as a permanent substitute for integration. A dozen bots papering over systems that could have been connected properly becomes its own maintenance department, and the cost tends to be invisible until the year it is not.
How Automathing approaches it
We check for a real integration path before proposing RPA, including asking the vendor directly, because an API almost always costs less over three years than a bot. When RPA is genuinely the right answer, we treat it as a bridge with a stated lifespan: monitored, documented, and with a plan for what replaces it. A bot nobody owns is a future outage.
Frequently asked questions
Is RPA obsolete now that we have AI?
No, but its role has narrowed. RPA is good at deterministic clicking; it has never been good at reading a document or making a judgment. AI covers the interpretation, RPA covers the access to systems that will not talk any other way, and the two are increasingly used together: the model decides what should happen, the bot performs it in a system with no API.
Is RPA cheaper than proper integration?
Cheaper to start, frequently more expensive to keep. The setup is fast because it needs no vendor cooperation, but maintenance is ongoing and unpredictable, since it depends on interfaces you do not control. Over a multi-year horizon, an API integration usually wins on total cost, which is why the honest comparison has to include maintenance rather than just the build.
What breaks RPA bots?
Interface changes, mostly: a moved button, a renamed field, a new consent dialog, a slower page. Also credential expiry, session timeouts, and anything requiring multi-factor authentication. Each is individually trivial and collectively the reason RPA needs monitoring and a named owner.
Can RPA handle exceptions?
Only the ones it was told about. RPA follows a defined path, so anything unanticipated causes it to fail or, worse, to proceed incorrectly. The usual design is to have the bot handle the standard path and route everything else to a person, or to place an AI step in front of it to interpret the input before the deterministic part runs.