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

Robotic process automation (RPA) is software that operates applications through their user interfaces the way a person would, clicking buttons, filling fields and reading what appears on screen. It needs no API, no integration and no cooperation from the system being automated. RPA is the right answer when a system offers no supported way in.

That is the reason RPA exists, and it is also the source of every complaint about it. 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

Key takeaways

• RPA operates a user interface, so it works on systems with no API but depends on screens that can change without notice.
• Each bot is coupled to an interface you do not control, so maintenance becomes the dominant lifetime cost.
• Give each bot its own account, store its credentials in a secret store, and tell your security team it exists.
• Use an API, an export or a database read instead whenever one is available and affordable.
• A bot should stop and capture a screenshot when it cannot continue, instead of guessing.

What it actually does

RPA executes the same actions a person performs on a screen: clicks, keystrokes and reading fields. Four properties define it:

• It operates the user interface. Software performs the actions a person would.
• 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. The system does not need to expose anything or know it is being automated.
• It sits on top and does not integrate. A bot inherits the interface's slowness and quirks. It is not intelligent by default: it follows a recorded or configured sequence, and any reasoning lives in whatever decides what to do.

The legitimate case

RPA is the right choice in five situations. It attracts both overselling and reflexive dismissal, so the cases are worth stating clearly:

• Systems with no API, such as legacy applications, terminal interfaces, desktop software and vendor systems that expose nothing.
• Systems whose API costs more than it is worth, such as a vendor charging heavily for API access on a process that runs fifty times a month.
• Systems you cannot change. Another department owns the system, the vendor's roadmap is full, and the work still has to happen.
• A bridge while a proper integration is built, with a known end date.
• High-volume, stable, rule-based work where the process does not vary and the screens rarely change.

Why bots break

Bots break for six reasons, listed in the order you will meet them. None is a bug in the target system, which is why nobody warns you they are coming.

1. The interface changed. A field moved, a label was reworded or a form gained a step. The bot cannot find what it expects.
2. A dialog appeared. A cookie banner, update prompt, survey or session warning stops a bot that was not told about it.
3. Timing. The bot acted before the page finished loading. This failure is intermittent, depends on the environment and frustrates people most.
4. A permission or state difference. The bot's account sees a slightly different interface from the one the process was recorded against.
5. Data variation. A record with an unusual value renders differently, a case that testing never met.

The maintenance cost nobody budgets

Maintenance is the cost to understand before adopting RPA at scale, because every bot is coupled to an interface you do not control, and interfaces change on someone 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, so 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 why RPA programmes are often judged to have failed.
• Name an owner per bot. An unowned bot that breaks is discovered when someone notices the work did not happen.
• Track break frequency per bot. A bot that breaks monthly costs more than it saves, and only measurement shows which bots those are.

Attended and unattended

Attended bots run beside a person and unattended bots run alone:

Type	How it runs	Strength	Requirement
Attended	On the person's machine, triggered by them	Easier to start	The person must be present, so it automates part of a task
Unattended	On a server, on a schedule or trigger	Where the savings are	Monitoring, credentials, error handling and somewhere to run

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

Credentials, and what a bot can reach

A bot logs in as someone, so it needs credentials to a system designed for human access, and its security posture is unusual.

• It often holds broad permissions, because it operates the interface and the interface belongs to a role, not 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, where they end up by default.
• Audit what it does. A bot with a user's permissions performing thousands of actions is the pattern security monitoring flags, so tell the security team first.
• 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

Use an API instead whenever one exists and is affordable, because an API is a contract and a screen is not. Treat RPA as the option when the alternatives are absent, and record why you chose it.

• Check again periodically. Vendors add APIs, and a bot built three years ago may automate a system that now offers a supported route.
• Check for an export or import. Many systems without a full API support file-based exchange, which is more stable than driving the interface.
• Check the database where you own the system. Reading directly is usually more stable than reading the screen that displays it.

Making a bot that fails usefully

A manageable bot differs from a fragile one mostly in what happens when it cannot continue. Six practices apply:

1. Stop instead of guessing. A bot that cannot find a field should fail, not click the nearest thing, which produces actions nobody intended in a system nobody watches.
2. Capture a screenshot on failure. The failure is visual, and a stack trace says nothing about what was on screen.
3. Identify elements by the most stable attribute available. Prefer the underlying control identifier to position, and position to image matching, since that order roughly matches how likely each is to survive a redesign.
4. Wait for conditions, not durations. A fixed pause is a timing bug waiting for a slower day, while waiting until an element is present is stable.
5. Handle the unexpected dialog explicitly. Dismiss known dialogs and stop on unknown ones.
6. Route failures to a person with context attached, so someone triages an exception instead of discovering missing work later.

Where CodeWords fits

CodeWords covers the API-connected half of this problem. Describe an outcome in plain language, and Cody, the automation builder, builds, connects and deploys the automation across 3,000+ integrations (CodeWords integrations page, 2026). 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, including the exceptions.
3. Connect the systems involved once and reuse the connections.

The Free plan covers light use. Pro costs $39 per month and Business costs $100 per month (CodeWords pricing page, 2026). Details are on the pricing page.

What to get right first

Write down, for each bot, why RPA was chosen over an API, an export or a database read. It takes a sentence, and it lets someone revisit the decision when the vendor ships an API two years later, which happens and which nobody notices while the bot still works.

Two habits make the difference. Budget maintenance explicitly instead of 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 costs more than it saves and nothing else identifies it.

Frequently asked questions

When is RPA the right choice?

RPA is the right choice when the system has no API, when the API costs more than the process is worth, or when you cannot get the system's owner to make a change. It is the option when the others are absent, not a first choice.

Why do bots break so often?

Bots depend on an interface nobody promised to keep stable. A moved field, a reworded label, an unexpected dialog or a slow-loading page can each stop a bot, and none of them is a fault in the target system.

What does RPA actually cost?

RPA costs the build plus ongoing maintenance that grows roughly with the number of bots, since each bot is coupled to an interface that changes on someone else's schedule. Business cases that omit maintenance are why programmes get judged as failures.

Should I choose attended or unattended bots?

Unattended bots deliver the savings, and they need real operational support: monitoring, credentials, exception handling and somewhere to run. Attended bots are easier to start but deliver less, because a person still has to be present.

What credentials should a bot use?

A bot should use its own account, never a person's, with credentials held in a secret store and not in the bot definition. Tell your security team it exists, since thousands of actions under a user's permissions is a 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. Organisations then maintain screen automation against a system that already offers a supported route.

Is RPA the same as intelligent automation?

No. RPA drives an interface, and intelligent automation adds judgement about what to do. The two are often combined but they are different things, and conflating them credits RPA with capabilities it does not have.

What should a bot do when it cannot find something?

A bot should stop and capture a screenshot. A bot that guesses clicks something nobody intended in a system nobody is watching, and the screenshot is the most useful diagnostic because the failure is visual.

How do I make bots less fragile?

Identify elements by the most stable attribute available, preferring an underlying control identifier to position and position to image matching. Wait for conditions and not fixed durations, because timing assumptions cause the most intermittent failures.

Related reading

• Business process automation
• Intelligent automation
• Hyperautomation