RPA or a Real Integration? A Decision Guide

Robotic process automation drives an application the way a person would: it clicks the buttons and types in the fields. An integration talks to the system through a documented interface. Both move data from A to B, and they fail in completely different ways.

The honest trade-off

RPA is fast to stand up, needs no cooperation from the vendor, and works against systems that have no API at all. In exchange, it breaks when a field moves, when a dialog appears, or when the login page adds a step. It is automation built on the assumption that the user interface is a stable contract, which is the one thing a user interface never promises.

An API is a promise the vendor made. A screen is a layout they can change on Tuesday.

When RPA is the right answer

• The target system genuinely has no API and no database access.

• The vendor is a third party you cannot influence.

• The process is due to be retired within a year or two.

• You need a bridge while a proper integration is built.

• Volume is low enough that occasional manual repair is acceptable.

When it is not

• An API exists and is documented — use it, even if it takes three times as long.

• The process is core and permanent.

• The bot needs privileged credentials on a system of record.

• The volume means a silent failure would take days to notice.

• Correctness matters more than throughput — a half-completed bot run can leave records in states the application would never produce.

The tactical debt test

Ask one question: what is the plan for retiring this bot? A credible answer — a named integration on a roadmap, a system replacement with a date — makes RPA a sensible bridge. No answer means you are choosing a permanent solution with the maintenance profile of a temporary one, and the maintenance will land on whoever inherits it.

If you do build bots, build them observably

The worst failure mode is not a bot that crashes; it is a bot that appears to run and quietly stops processing. Treat each run as a job with an expected outcome.

• Alert on zero items processed, not just on errors.

• Reconcile counts at both ends daily.

• Give the bot its own named credential, never a person's.

• Make every run idempotent so a re-run after failure is safe.

• Keep a screenshot or trace of the failing step for diagnosis.

A bot with those properties is a legitimate engineering artefact. A bot without them is a scheduled task that everyone hopes is working.