The reputation problem
RPA is sold on demonstrations of a robot filling in forms. That is what people picture.
It is also the least reliable thing RPA does, and in well-built automations it is often a small part of the whole.
Much of what production RPA actually does:
Downloads a file. Extracts an archive. Checks the file is what it should be. Sends it somewhere. Logs the outcome. Fails cleanly when something is wrong.
None of that involves a screen. And all of it is work somebody currently does by hand.
Working with files
The most common thing production automations do, and the least discussed.
Downloading. Not always by navigating a site — often by making an HTTP request directly to a URL, which is faster and far more reliable than driving a browser.
Extracting archives. Data is frequently published as a ZIP containing one or more files.
Finding the right file. An archive may contain several. Picking the newest by modification time is a common and sensible rule.
Validating. Does the file exist? Is it the expected type? Does it have content?
Moving it on. To another system, an API, or a folder something else watches.
FIGURE 1: A FILE-HANDLING AUTOMATION
Download
- HTTP request, or navigate if there is no direct URL
Extract
- Unpack the archive to a working folder
Find and validate
- Newest file, correct type, has content
Hand off
- Upload to the next system
Why an HTTP request beats a browser
Worth being explicit, because this is where a lot of unnecessary fragility comes from.
If a file has a direct URL, request it. Do not open a browser, navigate to a page, and click a link.
Three reasons:
Reliable. No layout to change, no element to move, no popup to interfere.
Fast. No browser to start, no page to render.
Debuggable. An HTTP request either succeeded or returned a status code that tells you why not.
Navigate only when there is no direct URL — when a login is required, or the link is generated per session.
And when you must navigate, do as little as possible. Get to the file and stop.
Handing off to the next system
An automation that downloads a file has to give it to something.
A common and sensible pattern: upload the whole file in one request to a workflow tool or an API endpoint, and let that handle the contents.
Why the whole file rather than row by row:
Fewer executions. A 500-row file sent row by row is 500 calls. Sent whole, it is one.
Less duplicate risk. A partial send that gets retried can produce duplicates. One file either arrived or did not.
Clearer failure. “The upload failed” is easier to reason about than “rows 1–340 arrived”.
Cleaner separation. The automation’s job is getting the file. Understanding the contents is the next system’s job.
FIGURE 2: HANDING OFF A FILE
Whole file, one request
- One execution regardless of size
- Either it arrived or it did not
- Retry is safe
- The next system owns the parsing
Row by row
- Hundreds of executions
- Partial sends are possible
- Retries can duplicate
- Two systems both parsing
Validation before handing off
Check before you send.
Was a file found at all? The archive might have been empty, or the download might have produced an error page.
Does it exist on disk where you expect? Extraction can fail silently.
Is it the right type? A CSV that is actually an HTML error page is a classic failure — the download “succeeded” and returned the wrong thing.
Does it have content? A zero-byte file is not data.
Failing here is much better than failing later. A bad file caught before upload is a clear error. A bad file uploaded is a confusing problem in another system.
Error handling
This is where RPA earns its place as an orchestration tool.
Wrap each stage in try-catch. Download, extract, find, validate, upload — each its own protected block, so you know which one failed.
Log the error message and the stack trace. When it fails overnight, that log is what tells you what happened.
Re-throw so the job is marked failed. This matters more than it sounds. An automation that swallows an error and exits successfully is the worst outcome — the orchestrator records a success, nobody is alerted, and the data silently did not arrive.
A failed job is visible. A quietly-succeeded failure is not.
FIGURE 3: ERROR HANDLING THAT WORKS
Try-catch per stage
- So you know which step failed, not just that something did.
Log message and stack trace
- It fails at 3am. The log is all you will have.
Re-throw so the job fails
- A swallowed error means a false success and no alert.
Alert a named person
- Not a log file. Somebody who will act.
Capturing the response
If your automation calls an API or uploads a file, check what came back.
The status code. Success or failure, and which kind.
The response body. The receiving system may tell you something useful — how many rows it accepted, what it rejected.
Log both. A successful upload with a response saying “0 rows processed” is a failure wearing a success badge, and only the response body reveals it.
Where this leaves screen automation
Still necessary, sometimes. A portal with a login and no direct file URL. A desktop application with no API. A system nobody can change.
But it should be the minority of what an automation does, and it should be confined to the smallest possible step.
A good design: screen work to get past the thing that requires it, then ordinary reliable methods for everything after.
When the site redesigns — and it will — you fix one step.
The short version
RPA is not only screen automation, and in production it often mostly is not.
Downloading, extracting, validating and handing off is the bulk of the work, and it is far more reliable than clicking.
Use HTTP requests where a direct URL exists. Send whole files rather than row by row. Validate before handing off.
And re-throw errors so the job fails visibly. A swallowed error is a silent gap in your data that nobody discovers for weeks.
Somebody downloading and checking files every morning?
Get in touch. Most of that work is orchestration rather than screen automation — which makes it far more reliable than people expect.
