Which Processes Suit UiPath RPA, and Which Do Not
This is the section that decides whether your programme works. Choosing the wrong first process is the most common way an automation effort quietly ends.
The Five Properties of a Good Candidate
A process worth automating has all five. Four out of five is usually a no.
It is rule-based. Every decision in it can be written down as a rule. Not usually approved if it looks reasonable, but a condition somebody can state. If the process depends on judgement, the judgement has to come out of the automation and sit with a person.
It repeats often. Frequency is what pays back the build. A process run four hundred times a month is a candidate. A process run twice a year, however painful, is not, and the automation for it will cost more to maintain than the manual version costs to run.
The applications are stable. The screens the robot drives need to still look like this next quarter. A system mid-replacement, mid-upgrade or in active development is the worst possible target, and this is the property teams most often ignore.
The data arrives structured. A spreadsheet, a database row, a well-formed file. Free text, photographs of paper and handwriting are a document understanding project wearing a disguise, and that is a separate initiative.
The exception list is short enough to build. Every process has exceptions. The question is whether you can name them. If the people who run it say it depends more than three times in one conversation, you are looking at a process that is mostly exception, and automating the happy path will produce a robot that hands almost everything back.
RPA Use Cases That Keep Paying
The use cases that survive have the five properties and tend to cluster in the same places.
Finance. Invoice processing where the data arrives in a consistent format, payment runs, reconciliation between two systems that were never connected, month-end reports assembled from four sources by hand.
HR. Onboarding, which is usually the same twelve account-creation steps across six systems, and the leaver process, which matters more than it gets credit for because a missed access revocation is a security finding.
Claims and case handling. Intake, validation against rules, routing. The judgement stays with the assessor; the fetching, checking and recording does not.
Order processing. Taking an order from one system and entering it into another, with the validation in between.
Regulatory and periodic reporting. Same shape every time, painful deadline, high cost of a transcription error.
What these share is not the department. It is that a person is currently acting as an integration between two systems, and doing it hundreds of times. Our post on how RPA is transforming business processes has more on the patterns.
The Processes You Should Not Automate
The list nobody publishes, and the more useful half of the question.
The process that is about to change. If the system is being replaced in eighteen months, you are building something with an expiry date. Sometimes that is still worth it. Decide deliberately rather than discovering it later.
The process that is mostly exception. If forty per cent of cases need a human decision, the robot becomes a sorting mechanism that hands most of the work back, and you have added a step rather than removed one.
The process nobody has written down. Automating a process that exists only in one person's head means encoding their habits, including the workarounds they invented for a problem that was fixed two years ago.
The process that should be fixed instead. This is the big one. A great many high-volume manual processes exist because a form is badly designed, two systems were never connected, or a report cannot be scheduled. Automating them makes a bad design permanent and cheap to live with, which guarantees it will never be fixed.
The process with a real integration available. If an API exists and the effort is comparable, use it. Robots are what you reach for when integration is unavailable or uneconomic, not when it is merely more work.
The process where a mistake is expensive and undetectable. Anything touching payments, entitlements or regulatory submissions where a wrong value would not be noticed for weeks. Automate the preparation, leave the commitment with a person.
Finding Them Honestly: Process Discovery Before Tooling
Every organisation starts the same way: somebody asks which processes should be automated, and the answer comes from whoever is loudest about their workload.
That is not discovery. Discovery is finding out what people actually do, how often, and how much it varies. Three ways, in increasing cost.
Ask, then watch. Interview the team, then sit with them while they work. The gap between the described process and the observed one is where all the exceptions are hiding, and it is always larger than anyone expects.
Read the logs. Process mining reconstructs the real path from system event data. It is objective, it covers everything rather than a sample, and it needs decent logs to work with.
Instrument the desktop. Task mining watches what people click. It is the most complete picture and the most sensitive, so it needs a conversation with staff and quite possibly a works council before you switch it on.
Whatever the method, the output is the same: a list of candidate processes with a volume, a variation estimate and a named exception list. Rank by volume times how similar each instance is to the last. Then apply the five properties. What survives both is your shortlist, and it is usually shorter and duller than the one people nominated.
