Some software will never give you an integration point — a supplier portal, a government system, an internal tool from 2004. RPA drives them the way a person would, which is both the appeal and the risk.
We'll always look for a real integration first, because a bot depends on a screen staying where it is. When there genuinely isn't one, the job is making that dependency as stable as it can be.
Judging which processes suit a bot at all — high volume, rule-based, and stable — and being direct about the ones that don't.
Targeting elements by the most durable identifier available, with fallbacks, so a cosmetic change doesn't stop the overnight run.
Authentication through a secrets store the bot requests at runtime, never pasted into the automation itself.
Retries with limits, timeouts, and a defined behaviour when the target system is down — which it will be, eventually, mid-run.
Cases the bot can't complete routed to a person with the record and the reason, instead of vanishing from the process.
Run history, success rates, and alerting, because the worst failure mode is a bot that stopped working three weeks ago unnoticed.
RPA earned its reputation for fragility honestly. Most of that fragility, though, comes from how the bots were built rather than from the approach itself.
Where an interface does exist, build the real thing instead — API development or business process automation.
Describe the system nobody can integrate with and the task being done by hand against it. We'll tell you whether a bot is the right answer or a liability.