What is Robotic Process Automation?
Also called RPA, screen automation.
Robotic process automation is a technique in which software drives existing applications through their user interfaces, clicking, typing, and reading the screen the way a person would, in order to move data between systems that offer no usable integration. Scripts are recorded or built step by step. Because they depend on the interface staying the same, they break when a screen changes.
The approach became widespread because many core business systems, particularly older ones, cannot be integrated any other way. Driving the interface is a workaround that requires no change to the underlying system, which is why it can be deployed quickly and also why it accumulates maintenance cost. A field that moves twenty pixels can stop a working script.
Typical uses are transferring records between systems, pulling reports on a schedule, reconciling two sources against each other, and filling forms in bulk. Programs are usually judged on transaction volume handled and error rate, and the durable ones are those where somebody owns script maintenance as continuing work rather than treating deployment as the end of the project.
The word robotic is misleading, since nothing physical is involved and the scripts are not intelligent. Vendors now market intelligent automation or agentic variants for products that add document understanding or model based decision steps on top. Underneath, the interface driving mechanism and its fragility are unchanged.
This technique sits under business process automation as one implementation option, and is generally the least preferred one when a real interface exists, because a documented interface does not move without notice. Digital worker is the packaging term that grew out of this category. Agents overlap with it where the hard part is interpretation rather than clicking.
Key points
- Drives application interfaces by clicking and typing
- Used where no usable integration exists
- Breaks when screens change, so maintenance is continuous
- Prefer a documented interface whenever one is available
In practice
A finance team receives supplier invoices in one system and pays them from another, with no connection between the two. A script opens the first system every morning, reads the new invoice lines, switches to the payments system, and enters them field by field. It saves an hour a day, and it stops working the week the supplier portal redesigns its login page.