The usual definition, and why it is incomplete

RPA — robotic process automation — is usually described as software that operates other applications the way a person would. It opens the application, clicks the buttons, types into the fields, reads the screen.

That is real, and it is not the whole picture.

In practice, a lot of production RPA does very little screen automation. It downloads files, extracts archives, checks that data arrived, calls APIs, moves things between systems, and handles the failures.

UiPath is a platform for building that kind of automation — screen work when nothing else can reach, and ordinary orchestration for everything else.

Knowing that changes how you evaluate it. A tool judged only on screen automation looks fragile. Judged as a way to run reliable scheduled processes, it looks different.

What it is genuinely used for

Four categories, and only the first is screen work.

Operating applications with no other interface. Older systems, desktop applications, portals you use but do not own. This is where screen automation is the only option.

File and data handling. Download, extract, validate, transform, move. Ordinary work that somebody currently does by hand.

Orchestration. Running steps in order, on a schedule, with proper error handling — and stopping cleanly when something goes wrong.

Bridging. Getting data from a place with no API into a place that has one, so the rest of the chain can be reliable.

The three pieces

A designer. Where you build. Activities on a canvas — download this, extract that, check it, send it on, log what happened.

A robot. The thing that runs it. On a desktop, or on a server.

An orchestrator. Schedules runs, assigns work, records what happened, handles retries.

A small team might use only the first two. The orchestrator matters once several automations run unattended and somebody needs to see what happened overnight.

Attended and unattended

Attended runs on a person’s machine, usually started by them. Good for work somebody triggers — processing a batch they just received.

Unattended runs on a server, on a schedule, with nobody watching. Good for overnight jobs.

Unattended needs more: error handling that works without a person present, logging detailed enough to explain a failure the next morning, and alerts that reach somebody.

Most businesses start attended. Lower risk, and you find out whether the process is stable before letting it run alone.

What suits it

Four characteristics. The more a task has, the better the fit.

High volume. The same thing, many times.

Rule-based. Clear steps, no judgement.

Structured input. Consistent format, same place each time.

A stable interface — if screen automation is involved.

What does not suit it: anything needing judgement, unstructured documents in varying layouts, low volume, and interfaces that change frequently.

The fragility, honestly

Screen automation depends on the screen staying the same.

A button moves, a field is renamed, a layout changes — and the automation breaks. Sometimes silently, clicking the wrong thing rather than stopping.

Which leads to the most useful design principle in this whole area:

Keep the screen-automation part as small as the problem allows.

If a process needs one step that genuinely requires a browser and eight that do not, do the one and let reliable methods handle the rest. When the site changes, one small step needs fixing rather than the whole chain.

The honest comparison with integration

An API integration is more reliable and cheaper to maintain. It does not break when a layout changes.

RPA is faster to a working result and needs no cooperation from anyone. That is its real advantage and also how it gets misused.

The rule: if an API exists and you can use it, use it.

And check properly. Automations get built against systems that turn out to have a perfectly good API nobody looked for. That is the most expensive avoidable mistake in this area.

Where UiPath sits

UiPath is one of the established platforms, alongside Automation Anywhere, Blue Prism and Microsoft Power Automate Desktop.

What it provides: a visual designer, a large activity library, an orchestrator, a community edition for learning, and a substantial ecosystem.

What it costs: enterprise RPA is priced per robot and per environment, and pricing changes. Get current figures from the vendor rather than any article.

The community edition is genuinely useful for finding out whether RPA suits your process before committing.

Is it right for you?

Four questions.

Do you have a specific repetitive task? Not “we do a lot of admin”. A named task, done many times, the same way.

Does an API exist? If yes, build an integration.

How often does the interface change? Frequently changing systems make fragile automations.

Who will maintain it? If the answer is nobody, do not start.

The short version

RPA is often described as screen clicking. In production it is usually file handling, orchestration and error management, with screen work only where nothing else reaches.

Keep the screen-automation part small. That single decision does more for reliability than anything else.

Check for an API first. An integration beats RPA whenever it is available.

And give every automation an owner. Unmaintained RPA breaks quietly, and quiet is the expensive kind.