First Principles: What Is Robotic Process Automation, and What Should It Touch?
Share the раgе:
Robotic process automation is software that operates existing applications through their screens, the way a person does, to execute rules-based steps without changing the underlying systems. That definition is accurate and tells a buyer nothing about where it belongs. The useful definition is by boundary: RPA fits where the process is stable, the rules are explicit, the volume justifies it, and the screens it drives will not change under it. It does not fit where a real integration is available, where the step needs judgement, or where the process is broken and automating it would only make the breakage faster. This guide gives the definition, a five-condition suitability test, the three places RPA should not go, and how it sits alongside integration and AI.
Introduction
The standard definition is "software robots that mimic human actions in digital systems." Every vendor page has a version of it. It is true, and it is why so many RPA programmes automate the wrong things.
Mimicking human actions is what RPA does. It is not what RPA is for. A person clicking through six screens to copy a number from one system to another is not a process worth preserving. It is a missing integration with a person standing in for it. Sometimes RPA is the right way to fill that gap. Sometimes it is a way to make the gap permanent.
The difference is decided before the bot is built, by looking at the process rather than the tool.
What is robotic process automation?
Robotic process automation is software that logs into applications, reads what is on the screen, types, clicks, copies, and posts, following explicit rules, in order to complete repetitive steps that would otherwise be done by a person at a keyboard. It works at the user interface layer. It does not need an API, a database connection, or any change to the systems it operates.
Three things follow from that definition and matter more than the definition itself.
It is deterministic. An RPA bot does exactly what its rules say, every time, and nothing else. If a screen changes, a field moves, or an input arrives in a form the rules did not anticipate, it stops or does the wrong thing. It does not interpret.
It is non-invasive. Because it uses the interface a person would use, it can be deployed against systems nobody is allowed to modify: the legacy platform with no API, the vendor portal, the government filing system. That is its real advantage, and also the reason it is often chosen when a proper integration would have been better.
It is a bridge, not a fix. A bot moving data between two systems is doing work that should not exist. It is worth doing when the alternative is a person doing it for five more years. It is a mistake when it stops anyone from building the integration that would remove the work.
Key Takeaway: RPA is a way to do a person's clicks without the person. Whether those clicks should exist is a separate question, and it comes first.
Deciding whether a process belongs in RPA, in an integration, or nowhere yet? Our Low-Code & RPA practice runs the suitability test before the build. Book a free consultation.
Where does RPA belong, and where does it not?
Five conditions. A process needs all five to be a clean RPA candidate. Four out of five usually means a different tool or a fix to the process first.
The fourth row is the one most often skipped, because RPA is fast to start and integrations are not. The trade is that a bot driving a screen is fragile in a way an API call is not, and every interface change becomes a maintenance ticket. Choosing RPA when an integration exists is borrowing against future support cost, and the loan comes due at the next system upgrade.
The first row is where most of the surprises live. A process that looks rules-based from the outside usually has judgement in it that the person doing it has stopped noticing. "If the vendor name looks slightly different I check the address" is judgement. It becomes visible only when someone sits with the person and asks what they do at each fork.
Most RPA candidates arrive as a list of "repetitive tasks" nominated by the teams doing them, which measures frustration rather than suitability. ID Business Analysis Canada replaces that list with a process suitability assessment as the first deliverable of any RPA engagement, with a process analyst scoring each candidate against the five conditions above from observed cases rather than interviews, so the build queue contains processes that will hold rather than processes that are annoying.
Key Takeaway: Five conditions, all required. The one people skip is whether a better door than the screen already exists.
What should RPA touch first?
The first process should be the one that is boring in every dimension. High volume, fully rules-based, structured inputs, stable screens, no integration available, and a recoverable outcome if the bot gets it wrong.
That description usually points at the same handful of processes across organizations: transferring approved data between two systems that do not talk to each other, generating a standard report on a schedule from a system with no export, reconciling two lists that should match, or filing a routine submission to an external portal.
None of these is exciting. That is the point. The first bot exists to prove the operating model: who monitors it, who fixes it when a screen changes, how exceptions reach a person, and what the audit trail looks like. Prove that on a process where a failure costs an hour, before moving to one where a failure costs a customer.
Two things to measure on the first candidate before build:
- Exception rate from real cases. Pull the last ninety days. Count how many would have fallen off the rules. If it is above about one in ten, the process is not ready, and the exceptions need to be either designed into the rules or routed to a person by design.
- Screen change history. Ask IT when each application in the path last changed its interface, and when the next change is planned. A bot built three weeks before a platform upgrade is a bot built twice.
Key Takeaway: Start with the process where failure is cheap and the operating model gets tested. Save the important process for the second bot.
What should RPA never touch?
Three categories, and each one is a common early candidate because it is visibly painful.
Steps that need judgement. Anything where the person doing it interprets, weighs, or decides with context the system does not hold. RPA will execute a rule where a judgement was required and do it confidently, at volume, until someone notices. Where the judgement is bounded, an AI step with a confidence threshold may fit. Where it is open, the step stays with a person.
Processes that are broken. If the process produces wrong outputs, has three teams doing the same step differently, or exists only to correct errors upstream, automating it preserves the breakage and removes the person who was quietly compensating for it. Fix the process, then decide whether anything left is worth automating. Often it is not, because the fix removed the work.
Interfaces you do not control. A bot driving a vendor's web portal, a government filing site, or a SaaS product on a monthly release cycle will break on a schedule you do not set. Sometimes that is still the best available option. It should be chosen knowingly, with a maintenance budget, and not discovered when the bot stops on a Monday morning.
The failure patterns that show up once these three are ignored, and how to recover from them, are covered in our earlier piece on why RPA fails in production. This post is about not getting there.
Key Takeaway: Judgement, broken processes, and interfaces you do not own. Painful is not the same as automatable.
How does RPA fit alongside integration and AI?
As one of three layers, each with its own job, and the mistake is using one where another belongs.
- Integration layer. APIs, file interfaces, middleware, iPaaS. Moves data between systems reliably, does not care what the screen looks like, survives interface changes. The right answer whenever it is available, and worth building even when it is slower to start.
- RPA layer. Drives the screens of systems that offer no other door. Deterministic, fast to deploy, fragile to interface change. The right answer for the legacy platform, the portal, and the bridge that will exist until the integration does.
- AI layer. Handles the interpretive steps neither of the others can: reading a document in any layout, classifying a request, extracting fields from unstructured input. Works inside a confidence threshold with a fallback to a person, and hands its result to the integration or RPA layer to act on.
A mature automation stack uses all three, with the integration layer doing most of the moving, RPA doing the bridging that cannot be integrated yet, and AI doing the reading that cannot be rules-based. The ratio shifts over time as integrations get built and bots get retired. A programme where the RPA share keeps growing is a programme that stopped building integrations.
Key Takeaway: RPA is the middle layer, for the doors that have no other key. If the RPA estate keeps growing, ask why the integrations are not getting built.
Frequently Asked Questions
What is the difference between RPA and workflow automation?RPA operates the screens of existing applications to execute rules-based steps, one application at a time, as a person would. Workflow automation orchestrates a sequence of steps across people, systems, and bots, with routing, approvals, and state tracked between them. RPA is often one step inside a workflow. Workflow automation without RPA is common; RPA without a workflow around it usually becomes a collection of unmanaged bots.
Is robotic process automation the same as AI?No. RPA follows explicit rules and does not interpret anything. AI models interpret unstructured input and make bounded decisions with a confidence level. The two are complementary: AI reads the invoice in any layout and extracts the fields, RPA posts those fields into the finance system that has no API. Vendors bundle them as intelligent automation, which is a fair description of the combination and not a reason to skip the question of which layer each step belongs in.
How do we start with RPA if we have never used it?Start with a process suitability assessment rather than a tool selection: take the processes people have nominated, score each against the five conditions of explicit rules, structured inputs, stable screens, no better door, and sufficient volume, using observed cases from the last ninety days. ID Business Analysis Canada delivers that assessment in three to four weeks, with a process analyst producing the scored candidate list, the exception rate for each, and the recommended first bot, chosen for a cheap failure and a provable operating model. Tool selection follows from the candidate, not the other way round.
How long does an RPA bot last before it needs rebuilding?As long as the screens it drives stay the same. On a stable internal system that changes once a year, a bot can run for years with light maintenance. On a vendor portal or SaaS product with monthly releases, expect repairs on the vendor's schedule. The planning question is not how long the bot lasts but who owns it when it breaks and what the repair budget is, and both should be decided before the first build.
Conclusion
The definition is easy. Software that does a person's clicks. What decides whether an RPA programme pays is the harder question in the title: which processes it should touch, which should go to an integration or an AI step, and which should be fixed before anything is automated.
If you have a list of nominated processes and no way to tell which of them will hold, ID Business Analysis Canada's Low-Code & RPA practice runs the five-condition suitability assessment and returns a scored queue with the first bot identified. Book a free consultation and bring the list.
Sources