Robotic Process Automation (RPA) is a form of automation in which software robots operate existing applications through their user interfaces, clicking, typing, reading screens and moving data the way a person would, in order to execute repetitive, rule-based business tasks. Within RPA as a discipline, the robot is not a physical machine but a program that runs on a desktop or virtual machine and follows a recorded or designed sequence of steps.
RPA exists because many business processes span systems that lack usable APIs: legacy mainframe screens, desktop ERP clients, web portals of partners or applications delivered through remote desktops. RPA integrates them without changing the underlying systems, which makes it fast to deploy but also fragile when interfaces change.
How software robots perform a process
A software robot performs a process by locating interface elements, acting on them and reading the results, step by step, according to a workflow designed in an RPA studio. The decisive technical element is how the robot finds the right field or button on the screen.
The table below compares the main techniques robots use to identify and interact with interface elements.
| Technique | How it identifies elements | Reliability | Typical use |
|---|---|---|---|
| Selectors | Reads element attributes from the UI framework or browser | High | Web applications and modern desktop clients |
| Image recognition | Matches screenshots of buttons or fields | Medium | Remote desktop sessions and virtualized apps |
| OCR | Converts pixels on screen into text | Medium, depends on fonts and resolution | Reading values from virtual sessions |
| Coordinates | Clicks fixed screen positions | Low | Last resort when nothing else works |
| Keyboard and terminal emulation | Sends keystrokes and reads character fields | High on stable screens | Mainframe green-screen applications |
A production RPA platform has three layers: a design studio in which developers build workflows, robots that execute them, and an orchestrator or control room that schedules jobs, distributes work queues, stores credentials in a vault and keeps audit logs. The orchestrator is what turns individual scripts into a governed automation program.
Attended and unattended robots
RPA robots run either attended, alongside a person on the same desktop, or unattended, on their own on servers or virtual machines. The two modes serve different processes and are usually licensed differently.
| Aspect | Attended automation | Unattended automation |
|---|---|---|
| Started by | A user action on the desktop | A schedule, queue or event in the orchestrator |
| Runs on | The employee’s workstation | Dedicated virtual machines |
| Human role | Works in tandem, supplies input or decisions | Handles only exceptions afterward |
| Typical task | Prefill a customer record during a call | Process thousands of invoices overnight |
| Main benefit | Faster front-office work | Volume, 24-hour operation and consistency |
Many organizations combine both: an attended robot collects data during a customer interaction and places a work item into a queue, and an unattended robot completes the back-office processing later. This hybrid design keeps people in control of judgment calls while robots handle volume.
RPA compared with other automation approaches
RPA differs from API integration and workflow automation by working at the presentation layer instead of the data layer. That makes it the right tool when no interface for machines exists, but the wrong one when a stable API is available.
| Approach | Integration layer | Robustness | When to choose it |
|---|---|---|---|
| RPA | User interface | Sensitive to screen changes | Legacy systems without APIs |
| API integration | Application data and services | High, contracts are versioned | Systems with documented APIs |
| Workflow automation platforms | Mostly APIs and webhooks | High for supported apps | Cross-application SaaS processes |
| Business process management | Process models and human tasks | High, but slower to build | Long-running processes with many roles |
| Intelligent automation | RPA combined with AI services | Depends on model accuracy | Unstructured documents and emails |
A common view among practitioners is that RPA is often a bridge rather than a destination: it delivers value quickly while systems are old, and it is replaced by API integration once systems are modernized. Treating RPA as a permanent substitute for missing integrations tends to accumulate technical debt in the form of brittle bots.
Selecting processes and sizing robots
Good RPA candidates are processes that are high in volume, rule-based, based on structured digital input and running on stable applications. Processes that require frequent judgment, read handwritten documents or depend on screens that change monthly yield poor results.
Capacity planning starts from transaction volume and handling time. Suppose a process handles 20,000 transactions a month and a robot needs 1 minute per transaction. That is 20,000 minutes, or about 333 robot hours per month. An unattended robot available 20 hours a day for 30 days offers 600 hours, so one robot covers the load with about 45 percent headroom. The same work done manually at 5 minutes per transaction would take about 1,667 hours a month.
- Document the process precisely, including every exception path, before building the robot.
- Use dedicated robot accounts with least-privilege access and credentials stored in the vault, never personal logins.
- Design for exceptions: separate business exceptions, such as a missing invoice number, from system exceptions, such as a frozen window, and route each correctly.
- Monitor success rates per process, because a falling rate is usually the first sign that an application has changed.
Limitations and common failure points
The main limitation of RPA is brittleness: a robot depends on the exact behavior of interfaces it does not control. Maintenance therefore represents a substantial share of total cost, and an RPA program without a support model tends to degrade.
- Interface changes such as a moved button, a renamed field or a new pop-up stop robots until selectors are updated.
- Timing problems occur when a robot acts before a page has loaded; explicit waits for elements are more reliable than fixed delays.
- Automating a poor process locks in its inefficiency and makes it harder to redesign later.
- Security exposure grows when robots hold broad privileges, so robot identities need the same governance as human ones.
In plain words
Robotic process automation is a program that uses a computer the way an office worker does. It opens applications, reads what is on the screen, types into fields and clicks buttons, following exact instructions for a routine task.
It is useful when old systems cannot talk to each other directly. Instead of rebuilding those systems, the company lets the software robot act as the go-between. The catch is that the robot only knows the screens it was taught, so when a screen changes, someone has to update its instructions.
A real-world example
An insurance company receives about 8,000 claim payment requests a month through a partner portal. Clerks used to copy each request into a legacy claims system that runs in a remote desktop session and has no API, which took around 6 minutes per request, or roughly 800 hours a month.
The company deployed two unattended robots on virtual machines. Each robot reads new requests from the portal using browser selectors, enters them into the claims system using keyboard automation, and reads back the confirmation number with OCR. Requests with missing policy numbers or amounts above a set limit go to a human exception queue.
After stabilization, the robots processed about 92 percent of requests without human handling, and clerks focused on the remaining exceptions. The main ongoing effort was maintenance: when the portal changed its layout, the selectors were updated within a day, and the success rate dashboard showed the problem within the first hour.