RPA bots or a real integration: cost, fragility, and when each fits

Reference article · 6 min read

Agencies reach for robotic process automation when two systems will not talk to each other and staff are retyping data between them. A bot that drives the screen looks like the fast answer: no vendor negotiation, no interface specification, no waiting for a release train. Sometimes it is the right answer. Often it is a way of paying for the same integration twice, once in bot licenses and maintenance, and again in the real interface you end up building anyway.

The useful way to frame the decision is not automation versus integration in the abstract. It is a question of where the coupling lives: in a documented contract between two systems, or in the pixel layout of someone else's user interface. That choice determines what breaks, who gets the call when it breaks, and whether an auditor can reconstruct what happened.

What the options actually are

• Screen-level RPA. Software drives a human interface. It clicks fields, reads labels, and copies values. It signs in as a user and inherits that user's permissions. It sees what a person sees, including error pages it was never taught to read.
• API integration. Systems exchange structured data through a documented interface with versioning, defined error responses, and a service account scoped to specific operations. Screen changes do not affect it.
• File-based exchange. A scheduled extract, an agreed layout, a secure transfer, and a load with reconciliation. Unfashionable and durable. Good for batch work, poor when data must be current within minutes.
• Middleware or an integration platform. A broker that handles mapping, retries, queuing, and monitoring across several systems. Costs more up front and earns it back when the third and fourth interface arrive.

RPA is also used for work that is not integration at all: filling a form, assembling a packet, running a repetitive lookup. Those uses are legitimate, and the durability argument against bots is weaker there.

Build cost is not where the difference shows up

A bot is usually cheaper to stand up than an interface. It does not require the other vendor's cooperation, a contract amendment, or a joint test cycle. That gap is real, and it is also the narrowest part of the comparison.

The costs that follow are the ones agencies underestimate:

• A named owner per bot. Someone must watch runs, clear exception queues, and fix selectors. Unowned bots fail quietly until a program manager notices missing records.
• Test environments. A bot needs a non-production copy of the target system to rehearse against. If the vendor does not provide one, every change is tested in production.
• Patch days. Operating system, browser, and vendor releases all move things. Expect clustered failures after maintenance windows, including your own.
• Licensing per bot. Attended and unattended licensing differ, and unattended runners are the expensive kind. Model the tenth bot, not the first, and confirm how concurrency is counted.
• Change absorption. An API consumer reads a deprecation notice. A bot reads a screen that already changed.

Fragility and the audit trail

Screen automation fails in a way that structured integration mostly does not: it half-succeeds. A bot that completes three of five steps before hitting an unexpected dialog can leave a partial transaction in a system of record. Build every bot with a reconciliation step that compares what it intended to do against what the target system shows, and route mismatches to a human queue rather than a log file nobody opens.

Credentials deserve equal attention. A bot signing in with a named employee's account destroys non-repudiation and puts that employee's identity on every action. Give bots distinct service identities, store secrets in a managed vault rather than a configuration file or script, scope permissions to the minimum the task needs, and document any multifactor exception with your security office rather than working around it informally. Confirm that the source system's terms of use permit automated access; some vendor agreements restrict it.

Treat bot execution logs as records. If a bot touches eligibility, permitting, payments, or case files, its run history may fall within your retention schedule and may be responsive to public records requests. Confirm the treatment with your records officer and counsel rather than assuming, since retention rules vary by state and by record series.

When RPA is genuinely the right call

• The vendor will not expose an interface. No API, no export, no realistic path to one within your contract term.
• The bridge is short and dated. A replacement system is funded and scheduled, and the bot carries you to cutover. Write the sunset date into the project plan.
• Volume is low and the screen is stable. A weekly task against a system that changes rarely.
• The work spans systems you do not control. A state portal, a federal system, a payer site. You may have no standing to request an interface.
• You need evidence. A bot that quantifies a manual workload can justify the integration budget you were denied.

If none of those hold, and the same two systems will still be in place in several years, the interface is the cheaper answer even when it is the slower one.

What to ask vendors and put in the contract

Ask the owner of the source system, before you scope any bot:

1. Does a documented API or export exist, what does it cost, and is it already included in our current agreement?
2. Do your terms permit automated screen access by an agency-operated bot?
3. Will you provide a non-production environment, and how closely does it track production?
4. How much advance notice do you give of user interface changes, and through what channel?

Then put the answers in writing. Useful contract terms include interface documentation as a named deliverable, advance notice of changes that affect integrations, defined data extract rights that survive termination, and clear license true-up mechanics if bot counts grow. For internal governance, require a named owner, a documented sunset or review date, and reconciliation reporting before any bot is approved for production.

HQT works with state and local agencies on systems engineering and integration design, including deciding where automation belongs and where a durable interface is the better investment.

Frequently asked questions