Most automation advice assumes there's an API waiting for you. Often there isn't. A lot of real business work happens inside legacy desktop apps, government and bank portals, ERPs, and internal tools that were never built to be talked to programmatically. When there's no API, you automate the way a person does — through the interface. That's where RPA comes in, and UiPath is the tool I reach for.
API first, UI second
The first question I ask of any automation is: is there an API? If a system exposes one, I'd rather drive it through an integration (n8n, a backend service) than its screen. APIs are stable contracts; UIs are not.
RPA earns its place when that door is closed:
- Legacy or desktop software with no integration surface.
- Web portals you can only operate through a browser.
- Processes that span several systems that don't talk to each other.
- Document-in, system-out work — reading a file and keying it somewhere.
Think of RPA as a bridge across a gap the vendors never built, not as the preferred way to move data when a real connection exists.
What RPA is genuinely good at
UiPath shines on work that is repetitive, rules-based, and high-volume: the same sequence of clicks and keystrokes, done correctly, thousands of times, without fatigue. Data entry and migration between systems, reconciliations, pulling reports on a schedule, moving information from documents into an application — the unglamorous tasks that quietly eat hours.
The hard part is resilience
Anyone can record a happy-path workflow. Keeping it running is the real engineering. UI automation is brittle by nature: the moment a layout changes, a naive script breaks.
The patterns that keep mine alive:
- Anchor selectors on stable attributes, not screen coordinates or volatile labels. A selector tied to an element's identity survives a redesign that a pixel position won't.
- Wait for state, never sleep for time. Wait until the element exists and is ready, instead of hard-coding "pause three seconds" and hoping.
- Verify every step. After an action, confirm the expected result before moving on. A click that silently did nothing is worse than an error.
- Recover gracefully. Expect the popup, the timeout, the session drop. Route failures somewhere they're logged and retried, not swallowed.
Attended vs. unattended changes everything
An attended automation runs alongside a person who kicks it off and watches — forgiving, because a human catches the edge cases. An unattended one runs on its own on a schedule, on a robot/VM, with nobody looking. That's a different bar: it needs real error handling, logging, retries, and a queue (Orchestrator) so work is tracked and recoverable. Most of the value is in unattended automation, and most of the engineering is too.
Treat it like software, not a recording
The robots that last are the ones built like software: workflows in version control, configuration and credentials parameterized rather than hard-coded, executions logged, runs monitored. This is the same discipline I apply to reliable n8n workflows — idempotency, observability, explicit failure handling — just pointed at a UI instead of an API.
When not to use RPA
If there's an API, use it. RPA driving a screen is always more fragile than a real integration, so for a core, long-lived process, invest in the proper connection. I treat RPA as a pragmatic bridge: the right answer when the alternative is a human doing the clicking, and a thing to replace with an integration the moment one becomes available.
RPA and API-level automation aren't rivals — they're two ends of the same toolbox. The skill is knowing which gap you're crossing. If you've got a process trapped in a system with no API, let's talk — or see how I approach systems.