RPA vs traditional automation: how to choose
"Automation" covers two quite different approaches. One connects systems directly, behind the scenes. The other imitates a person using the screen. They suit different situations, and picking the wrong one is a common and costly mistake.
The two approaches
Traditional (integration-based) automation connects applications through their APIs, webhooks, database connections or built-in import and export. Tools like Zapier, Make, n8n and Power Automate do much of this work. The software exchanges data directly, without using the user interface.
Robotic process automation (RPA) uses a software robot that operates the application's user interface: it opens windows, clicks buttons, reads fields and types values. It works on anything a person can use, including systems with no API.
How they compare
| Integration-based | RPA | |
|---|---|---|
| How it connects | API, webhook, database, file import | Screen: clicks and keystrokes |
| Speed at runtime | Fast, runs in the background | Slower, follows screen response times |
| Fragility | Low, APIs change rarely and with notice | Higher: a layout change or pop-up can stop it |
| Works with legacy systems | Only if they expose an interface | Yes, if a person can use them |
| Build effort | Moderate, needs API knowledge | Moderate, but testing is lengthy |
| Running cost | Platform subscription | Licences, plus machines to run bots |
| Maintenance | Low | Ongoing |
A simple decision guide
- Does the system have an API or a built-in import? If yes, use integration. It is cheaper to run and more reliable.
- Is the vendor's API too limited or too expensive? Check the real price before deciding. Some vendors charge more for API access than the work is worth.
- Is the task rule-based, high-volume and stable? If yes, RPA is a candidate. If cases are mostly exceptions, neither approach will cope.
- Is the screen stable? If the application is updated often, bots will need frequent repair.
- Can you afford someone to own it? A bot without an owner breaks quietly and stays broken.
Three situations where RPA is the right call
A distributor entering customer purchase orders into an older desktop ERP with no import function. A finance team posting entries into a government portal that offers no integration. A hospital back office copying information between two systems that will be replaced next year, where a proper integration would cost more than the system's remaining life. The order entry case study follows the first of these.
Three situations where it is not
Moving data between two modern cloud apps that both have connectors. Processes still being redesigned. Work that needs judgement on most cases. In each, a standard workflow or a change to the process is a better answer.
The hybrid approach
Most real automation projects combine the two. An integration handles the cloud systems and triggers, and a bot takes care of the one legacy step at the end. Keep the RPA part as small as you can. Every screen a bot has to touch is a place where it can break.
Costs people overlook
Include maintenance in the business case. Bots need monitoring, credentials need rotating, and screens change. Ask for a three-year cost including support, not only the licence. If the saving only works on the licence price, it does not work.
For help deciding, see our RPA consulting and process automation pages. We will tell you plainly if the cheaper option is not RPA.
Related reading and services
Want to fix a process like this?
Book a free process review. Bring one slow process and leave with three improvement ideas.
Book a free review