What is RPA (robotic process automation)? A plain guide: how a software robot works, a side-by-side comparison with API-based automation, when RPA is the right answer for legacy systems and portals, and what UiPath, Power Automate Desktop and Automation Anywhere actually do.
Key takeaways
- RPA drives the user interface the way a person does; API-based automation exchanges data through an interface the software publishes. That one difference decides what breaks it and who maintains it.
- If the apps offer an API, integrate through it first; RPA is the fallback for systems that have no API and cannot be changed.
- The robot finds buttons and fields through selectors, so a moved button, a renamed field or a new pop-up can break it silently.
- RPA fits legacy desktop systems (VB6, classic Win32, terminal screens) and form-only portals with no API, or serves as a temporary bridge while a proper integration is built.
- The true cost is the platform license plus building plus a permanent maintenance commitment, and maintenance is the part people underestimate.
RPA (robotic process automation) is software that operates other programs the way a person does: it clicks buttons, types into fields and copies data between screens, following a fixed set of rules. Because it works through the user interface rather than a data connection, RPA can automate old desktop systems and portals that offer no API.
This guide compares RPA with API-based automation side by side, lists the situations where a screen robot is the right answer and the ones where it turns into a maintenance bill, and describes the three best-known RPA platforms using only what their vendors document.
What is RPA, and how does a software robot work?
An RPA robot replaces the clicks of an employee whose job is moving data between two programs that do not talk to each other: open system A, read a number, switch to system B, type it in, save, and repeat that 300 times a day. You record or configure those steps once, and the robot repeats them on the screen, faster and without typos.
The robot finds each button and field through a selector. UiPath's documentation describes a selector as the stored attributes of a user-interface element and of its parent elements, kept as an XML fragment, and notes that identifying elements by their position on the screen is unreliable. Microsoft Power Automate uses the same idea: every UI element consists of one or more selectors, and when one selector fails, the flow tries the next one in the defined order.
Robots run in two modes, a distinction both UiPath and Automation Anywhere draw:
- Attended - started by a person, on demand, to help with a task while they work, for example filling a form during a customer call.
- Unattended - run on a schedule or trigger with no human present, typically back-office data entry.
RPA is one technique inside the wider field of business automation for small business, not a synonym for automation in general.
How is RPA different from API-based automation?
RPA connects through the screen; API-based automation connects through a data interface the software publishes for other programs. That single difference decides what breaks the automation, how fast it runs and who has to maintain it.
| Criterion | RPA (screen robot) | API-based automation |
|---|---|---|
| How it connects | Drives windows, buttons and fields through selectors, like a user | Calls a documented interface (REST, SOAP, a database or a file import) and exchanges structured data |
| What breaks it | A moved button, a renamed field, a new pop-up, or an app update that changes element attributes | A new API version, expired credentials or a changed field in the payload, usually announced in advance |
| Speed | Bound by the application: the robot waits for each screen to load and render | Bound by the server and network; no screen to draw, and many systems accept records in batches |
| Maintenance | Recurring: selectors need repair after UI changes, and the robot needs a machine and a working user session | Lower and more predictable: versioned contracts, and failures come back as error codes you can log and retry |
| When to choose | No API, no reliable export, and software you cannot change | Whenever the system exposes an API or a reliable import/export |
The practical rule: if the system has an API, integrate through it first and treat RPA as the fallback. Most modern cloud software exposes one. For Israeli ERPs, the decisions that come before choosing a connection method are covered in connecting an Israeli ERP to other systems, and Zapier vs custom code covers when an off-the-shelf connector is enough on the API side.
When is RPA the right answer?
RPA is the right answer when a proper integration is genuinely impossible, not when it is merely more work. These are the cases where I recommend it:
- Legacy desktop systems with no API. An old Windows accounting or inventory program, an application built in VB6 or classic Win32, or a terminal (green-screen) system. Microsoft lists terminal emulators among the legacy applications its desktop flows can automate, and its UI elements documentation recommends the older MSAA selectors for VB6 and classic Win32 applications that do not expose modern UI Automation elements.
- Portals that offer only a web form. Government or supplier portals where the only way in is logging in and filling screens, with no published API or bulk upload. Check first: some Israeli government data is published through the data.gov.il CKAN API, and an API always beats a robot. Read the portal's terms of use before automating a login.
- Software you are not allowed to change. A vendor system or an internal application whose owner will not add an integration point.
- High-volume, stable, rule-based tasks. The same data-entry steps hundreds of times a day, on screens that rarely change.
- A temporary bridge. Relief for a painful manual process while the real integration, or a move from Access to a web system, is being built.
When is RPA the wrong tool?
RPA is the wrong tool whenever the screen is not the only way in, or the screen keeps changing. These are the situations where businesses pay for a robot that keeps breaking:
- The system has an API. Choosing RPA anyway means choosing the fragile, high-maintenance path on purpose.
- The interface changes often. UiPath's own documentation says some software, such as some web apps, has changing layouts and volatile attribute values that Studio cannot predict, so selectors may have to be built by hand. Every redesign is another repair.
- The task needs judgment. A robot follows fixed rules. Reading a messy email or deciding which customer an invoice belongs to needs logic or an AI layer, a line drawn in AI vs automation for business.
- It is a core process you will run for years. Over a long life, a proper integration usually costs less than repeatedly patching a robot, because an API never looked at the screen in the first place.
RPA tools: UiPath, Power Automate Desktop and Automation Anywhere
Three platforms appear on most RPA shortlists. This is what each vendor's own documentation says, not a ranking:
| Tool | What the vendor documents | Worth knowing |
|---|---|---|
| UiPath | Automations are built in Studio and run by robots in attended or unattended mode; elements are found through XML selectors | Applications with changing layouts may need selectors edited by hand |
| Microsoft Power Automate (desktop flows, Power Automate Desktop) | Desktop flows extend Power Automate's RPA capabilities, built from drag-and-drop actions or by recording; they automate legacy applications such as terminal emulators, modern web and desktop apps, and Excel files | A UI element can hold several selectors that are tried in order, and text-based selectors are described as more resilient to changes in an app's structure |
| Automation Anywhere | Describes unattended, attended and hybrid automations, and positions RPA as the execution layer that AI agents call on for rules-based tasks | Its own RPA page lists connecting to APIs among the tasks RPA handles, so a platform is not limited to screen clicks |
Licensing differs by platform, edition and robot type, and changes often. Read the current terms on each vendor's pricing page before comparing.
What does RPA really cost?
The real cost of RPA is the platform license plus building the robot plus a permanent maintenance commitment. The license is paid to the vendor and depends on the edition and on whether robots run attended or unattended. Building is a one-time effort. Maintenance is the part people underestimate: a robot that ran perfectly in January can stop in March because a vendor redesigned one screen, and the process stays down until someone repairs the selectors.
For a one-off bridge to a legacy system that is acceptable. For a core process, that recurring fragility often makes an API integration cheaper over its lifetime, even if it costs more to build at the start. For how my own projects are priced, see pricing; for the cost drivers across approaches, the guide to how much business automation costs.
So does your business need RPA?
A business needs RPA only when three things are true at once: the system has no API or reliable import, it cannot be changed, and a high-volume, rule-based task runs through its screens. In that narrow case RPA is the best tool available. In most other cases an API integration or custom automation will be more reliable and cheaper over time.
If you are not sure which side of that line you are on, book a call and tell me which systems you are trying to connect. You can also reach me through the contact form.
Sources
Frequently asked questions
What is RPA in simple terms?
RPA, or robotic process automation, is software that mimics a person using a computer - clicking buttons, typing into fields and copying data between screens - to do repetitive, rule-based tasks. It works through the visual interface of your existing apps, which makes it useful for old systems that have no API or other modern way to connect.
How is RPA different from regular API automation?
Regular automation connects systems through an API, a data interface the software publishes, so it is stable and does not care how the screen looks. RPA has a robot operate the screen like a person, so a moved button or new pop-up can break it. When an app offers an API, integrating through it is almost always the better choice.
Which RPA tools are the best known?
The three names on most shortlists are UiPath, Microsoft Power Automate with its desktop flows (Power Automate Desktop), and Automation Anywhere. All three support robots that run with a person present or unattended on a schedule. They differ in licensing, in their ecosystems and in how they build selectors, so compare them on your own screens and systems.
Is RPA expensive?
The real cost is more than the license. You pay the platform vendor for licensing, which depends on edition and robot type, then pay to build the robot, and then keep paying for maintenance, because RPA breaks whenever a screen changes. For a long-term core process, a proper API integration is usually cheaper over its lifetime.
Does my small business need RPA?
Probably not, unless you depend on a legacy system or a form-only portal that cannot be connected any other way. Licensing and constant maintenance make RPA a poor default for small businesses. For most needs, a direct API integration or custom automation will be more reliable and cost less over time.
Keep reading
Related service
Business Automation
I build custom automations that remove repetitive work end to end.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build. I reply within 24 business hours with a few targeted questions, then we walk through it on a free 30-minute call, with no commitment. You come away with a scope, a timeline and a fixed price - or a straight answer that it isn't worth building.