What is robotic process automation, and when is it the right answer?

Robotic process automation drives applications through their interfaces the way a person would — clicking buttons, filling fields, reading what appears on screen. No API, no integration, no cooperation required from the system being automated.

That is genuinely useful and it is the reason RPA exists. It is also the source of every complaint about it, because an automation that depends on where a button is depends on something nobody promised to keep stable.

What we'll cover

• What it actually does
• The legitimate case
• Why bots break
• The maintenance cost nobody budgets
• Attended and unattended
• Credentials, and what a bot can reach
• When to use an API instead
• Making a bot that fails usefully
• Where CodeWords fits
• What to get right first
• Frequently asked questions

What it actually does

It operates the user interface. Clicks, keystrokes, reading fields — the same actions a person performs, executed by software.

It identifies elements by position, by accessibility properties, by the underlying control identifier, or by image recognition, depending on the tool and the application.

It requires no change to the target system, which is the whole point: the system does not need to expose anything or know it is being automated.

It is not intelligent by default. A bot follows a recorded or configured sequence; the reasoning is in whatever decides what to do, not in the driving.

It sits on top rather than integrating, which means it inherits everything about the interface including its slowness and its quirks.

The legitimate case

Worth stating clearly, because RPA attracts both overselling and reflexive dismissal.

Systems with no API. Legacy applications, terminal interfaces, desktop software, and vendor systems that simply do not expose anything.

Systems whose API costs more than it is worth. A vendor charging substantially for API access, for a process running fifty times a month, is a real scenario where driving the interface is the rational choice.

Where you cannot get the change made. Another department owns the system, the vendor's roadmap is full, and the work still has to happen.

As a bridge, while a proper integration is built, with a known end date.

High-volume, stable, rule-based work in those systems, where the process does not vary and the screens do not change often.

Why bots break

The failure mode, in the order you will meet it.

The interface changed. A field moved, a label was reworded, a new step was added to a form. Nothing failed at the system's end; your bot simply cannot find what it expects.

A dialog appeared. A cookie banner, an update prompt, a survey, a session warning — anything unexpected on screen stops a bot that was not told about it.

Timing. The bot acted before the page finished loading, which is intermittent, environment-dependent, and the most frustrating category.

A permission or state difference. The bot's account sees a slightly different interface from the one the process was recorded against.

Data variation. A record with an unusual value renders differently, which was never encountered during testing.

None of these is a bug in the target system, which is why nobody tells you they are coming.

The maintenance cost nobody budgets

The single most important thing to understand before adopting RPA at scale.

Every bot is coupled to an interface you do not control, and interfaces change on somebody else's schedule.

Vendor updates are the usual trigger, and they arrive without regard for your automation.

The cost is ongoing and roughly proportional to the number of bots, which means a successful RPA programme becomes a maintenance programme.

Budget for it explicitly. Business cases built on build cost and savings, with no maintenance line, are the reason RPA programmes are frequently judged to have failed.

Nominate an owner per bot, because an unowned bot that breaks is discovered when somebody notices the work did not happen.

Track break frequency per bot. A bot breaking monthly is costing more than it saves, and only measurement surfaces that.

Attended and unattended

Attended bots run alongside a person, triggered by them, on their machine — automating part of a task rather than the whole of it.

Unattended bots run on their own, on a server, on a schedule or a trigger, with no person present.

Unattended is where the savings are and where the operational requirements are real: monitoring, credentials, error handling, and somewhere to run.

Attended is easier to start and delivers less, since it still requires the person to be there.

Unattended bots need a queue and an exception path, exactly like any other automated process, and the ones that fail quietly are the ones that had neither.

Credentials, and what a bot can reach

Worth its own section, because the security posture is unusual.

A bot logs in as somebody, which means it needs credentials to a system that was designed for human access.

It frequently has broad permissions, because it operates the interface and the interface belongs to a role rather than to a task.

Give it its own account, never a person's, so its actions are attributable and it survives that person leaving.

Store credentials in a secret store, not in the bot definition, which is where they end up by default.

Audit what it does. A bot with a user's permissions performing thousands of actions is exactly the pattern security monitoring is designed to flag, so tell them before they find it.

Consider what it can see. A bot reading a screen can read everything on that screen, including data unrelated to its task.

When to use an API instead

Always, if one exists and is affordable. An API is a contract; a screen is not.

Check again periodically. Vendors add APIs, and a bot built three years ago may be automating a system that now offers a supported route.

Check for an export or an import. Many systems without a full API support file-based exchange, which is far more stable than driving the interface.

Check the database, where you own the system, since reading directly is usually more robust than reading the screen that displays it.

Treat RPA as the option when the others are absent, rather than as a first choice — and record why it was chosen, so the decision can be revisited when circumstances change.

Making a bot that fails usefully

The difference between a fragile bot and a manageable one is mostly in what happens when it cannot continue.

Stop rather than guess. A bot that cannot find a field should fail, not click the nearest thing — the second produces actions nobody intended in a system nobody is watching.

Screenshot on failure. It is the single most useful diagnostic here, because the failure is visual and a stack trace says nothing about what was on screen.

Identify elements by the most stable attribute available — an underlying control identifier rather than position, position rather than image matching — since that ordering roughly matches how likely each is to survive a redesign.

Wait for conditions, not durations. A fixed pause is a timing bug waiting for a slower day; waiting until an element is present is stable.

Handle the unexpected dialog explicitly, dismissing known ones and stopping on unknown ones.

Route failures to a person with the context attached, so an exception is triaged rather than discovered later as missing work.

Where CodeWords fits

CodeWords is for the API-connected half of this: describe an outcome in plain language and it builds, connects, and deploys the automation across more than 3,000 integrations. Where a supported connection exists, it removes the reason to drive an interface.

1. Open CodeWords and start a new automation.
2. Describe what should happen to Cody, the automation builder, including the exceptions.
3. Connect the systems involved once and reuse the connections.

The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

What to get right first

A written reason for each bot recording why RPA was chosen over an API, an export, or a database read. It takes a sentence, and it is what allows somebody to revisit the decision when the vendor ships an API two years later — which they frequently do, and which nobody notices because the bot is still working.

Two habits make the difference. Budget maintenance explicitly rather than counting only build cost and savings, since interface coupling makes maintenance the dominant lifetime cost. And measure break frequency per bot, because a bot that breaks monthly is costing more than it saves and nothing else will tell you which ones those are.

Frequently asked questions

When is RPA the right choice?

When the system has no API, when the API costs more than the process is worth, or when you cannot get a change made by whoever owns the system. It is the option when the others are absent rather than a first choice.

Why do bots break so often?

Because they depend on an interface nobody promised to keep stable. A moved field, a reworded label, an unexpected dialog, or a slow-loading page all stop a bot, and none of them is a fault at the system's end.

What does RPA actually cost?

Build cost plus ongoing maintenance roughly proportional to the number of bots, since each is coupled to an interface that changes on somebody else's schedule. Business cases that omit the maintenance line are why programmes get judged as failures.

Attended or unattended?

Unattended is where the savings are, and it requires real operational support — monitoring, credentials, exception handling, somewhere to run. Attended is easier to start and delivers less, because the person still has to be there.

What credentials should a bot use?

Its own account, never a person's, with credentials in a secret store rather than in the bot definition. Tell your security team it exists, since a bot performing thousands of actions with a user's permissions is exactly the pattern their monitoring flags.

Should I replace bots with APIs when they appear?

Yes, and set a reminder to check. Vendors add APIs, and a working bot gives nobody a reason to look — which is how organisations end up maintaining screen automation against a system that has offered a supported route for two years.

Is RPA the same as intelligent automation?

No. RPA drives an interface; intelligent automation adds judgement about what to do. They are frequently combined and they are different things, and conflating them is how RPA gets credited with capabilities it does not have.

What should a bot do when it cannot find something?

Stop, and capture a screenshot. A bot that guesses clicks something nobody intended in a system nobody is watching, and the screenshot is the single most useful diagnostic because the failure is visual rather than logical.

How do I make bots less fragile?

Identify elements by the most stable attribute available — an underlying control identifier before position, position before image matching — and wait for conditions rather than fixed durations. Timing assumptions are the most common intermittent failure.

Related reading

• Business process automation
• Intelligent automation
• Hyperautomation