RPA Process Selection: Criteria Catalog for Automatable Processes

Not every process that feels repetitive is automatically suited for Robotic Process Automation. Before you invest time in recording and building a desktop flow, it's worth taking a sober look at the process itself: How rule-based is it, how stable is the interface it works with, and how often is it actually executed? In its official Power Automate documentation, Microsoft deliberately distinguishes between two types of automation, API-based digital process automation and UI-based robotic process automation, and this distinction is precisely the first filter in every criteria catalog for process selection.

This article shows you which criteria to use when evaluating processes for RPA, when you're better off relying on API-based cloud flows, and how process and task mining help you find candidates systematically instead of picking them by gut feeling.

RPA or API Automation After All?

The first step in any process selection isn't an RPA question at all, but an architecture question. According to the Microsoft documentation on automation types you should prefer digital process automation via cloud flows for every application that has a ready-made connector or an open API. According to Microsoft, APIs generally remain stable even as an application evolves further, because software vendors actively take care not to break existing interfaces.

RPA only comes into play when exactly that is missing: a legacy application, old Windows software, or a web portal without a documented API. With RPA, you teach Power Automate to mimic mouse clicks and keyboard input the way a human would. The downside is stated explicitly in the same documentation: RPA is prone to breaking when the interface layout changes or the local machine is updated, and the instructions given to the bot must be very precise, for example whether it really always means cell B3 or the first empty cell in column B. That's why a criteria catalog for RPA doesn't just ask whether a process can be automated, but also whether RPA is even the right type of automation for it.

The Criteria Catalog: Seven Characteristics of a Good RPA Candidate

The more of the following points apply, the better suited a process is for RPA. If several of them are missing at once, either a process change is needed before automation, or a different automation approach makes more sense.

• Rule-based without room for discretion: The process follows fixed if-then logic instead of case-by-case decisions. As soon as a case worker decides based on experience or gut feeling, the process is unsuitable for classic RPA, unless you supplement it with AI-supported intermediate steps.
• High volume and regular repetition: A process that's done manually in five minutes ten times a year rarely justifies the effort of recording, testing, and maintaining a bot. Processes with daily or weekly runs pay off much faster.
• Structured, digital input data: Forms, tables, emails with a fixed format, or database fields can be read reliably. Handwritten notes, unstructured free text, or phone calls are a poor starting point for pure RPA.
• Stable application interface: Because RPA, according to Microsoft, works directly with the screen interface, you need applications whose layout rarely changes. Frequently updated web apps with shifting element positions significantly increase the maintenance risk.
• Clearly defined start and end point: A good candidate starts with a clear trigger, such as an incoming email or a new record, and ends with a verifiable result. Processes that stretch over several days or wait for external feedback can be automated, but need cleaner process modeling.
• Low exception rate: If the process runs exactly the same way in more than 80 to 90 percent of cases, automating the standard path is worthwhile, while rare exceptions continue to be handled manually or escalated to a human.
• Measurable benefit: Time savings, error reduction, or faster throughput time should be roughly quantifiable in advance. Without a quantifiable benefit, there's no basis for justifying the effort of building and operating a bot.

Attended or Unattended: The Process Determines the Operating Mode

Even if a process is fundamentally suited for RPA, the appropriate operating mode varies greatly. With attended RPA the bot works directly together with a person who starts the run and sits at the screen, for example for customer service tasks where an employee checks the final step. With unattended RPA, the process runs completely in the background without human supervision.

For unattended candidates, according to the Microsoft documentation on unattended desktop flows, additional technical requirements apply that should already be considered during process selection:

• The target machine must be fully logged off and available; on Windows 10 and 11, even a locked active session prevents the unattended run.
• The screen resolution of the remote session can differ from the resolution the flow was originally recorded with, which can cause errors with UI elements if it isn't fixed in advance.
• Unattended runs cannot be executed with elevated privileges, which can be an exclusion criterion for processes with admin requirements.

Processes that should run at night, on weekends, or at high frequency, such as invoice import or master data reconciliation, are classic unattended candidates. Processes with approval steps or situational review tend to remain with attended RPA or a hybrid of cloud flow and approval step.

Finding Candidates Systematically Instead of Guessing

Instead of selecting processes by gut feeling, Power Automate offers two tools, process mining and task mining, that identify candidates on a data-driven basis. According to the Microsoft overview of process and task mining, process mining is better suited for making inefficiencies visible in company-wide workflows such as accounts receivable or order-to-cash via event logs. Task mining, on the other hand, zooms in on individual desktop activities by analyzing recorded user actions and showing which applications tie up the most time.

Both features flag automation candidates directly in the process map. According to the documentation on automation recommendations, blue recommendation icons on activities in the process map indicate where automation makes sense. Via the option Automate activities you go directly to the Power Automate form designer, which provides matching connector suggestions for the flagged activities. This way you can see at a glance whether an activity is better solved via a standard connector as a cloud flow or actually via RPA.

Practical Checklist: Five Steps to a Solid Candidate

1. Delimit the process cleanly: Define the start, end, and all variants before you even talk about automation.

2. Check the API option: If a connector or an open API exists for the applications involved, cloud flow automation is almost always the more robust choice.

3. Apply the criteria catalog: Check rule-basedness, volume, data structure, UI stability, exception rate, and benefit using the seven characteristics above.

4. Determine the operating mode: Decide, based on supervision needs and frequency, whether attended or unattended RPA is the right fit.

5. Validate with data: Use process or task mining to check your assessment against real execution data instead of assumptions.

Anyone who consistently works through these five steps avoids the most common cause of failed RPA projects: a bot built on an unstable or too-infrequently-run process that, after just a few weeks, causes more maintenance effort than it saves. If you're unsure which of your processes are actually ripe for automation, a structured stocktaking often helps more than trying to tackle the biggest process right away. With the Power Automate consulting from NordFlux we go through exactly this criteria catalog together with you across your process landscape, so that your digital workers are deployed where they truly make an impact, while you retain full control over selection and operation at all times.

Frequently Asked Questions

What is the most important criterion in RPA process selection?

There isn't a single most important criterion, but rule-basedness carries the most weight: as soon as a process requires situational discretionary decisions, classic RPA hits its limits, regardless of how high the volume or benefit otherwise is. So first check whether the process really runs according to fixed rules before you assess the remaining criteria.

When should I automate a process via cloud flows instead of RPA?

Whenever a connector or an open API exists for the applications involved. According to Microsoft, APIs are significantly more stable than user interfaces, because vendors actively avoid breaking existing interfaces, while screen layouts change frequently with updates, making RPA flows more prone to failures.

How do I find RPA candidates without evaluating every process individually?

Process mining and task mining in Power Automate automatically evaluate event logs and recorded user actions and flag automation opportunities directly in the process map. This replaces manual individual review with data-driven prioritization and simultaneously shows whether a connector or a desktop flow is the more suitable solution.

What distinguishes attended from unattended RPA in process selection?

Attended RPA is suited for processes where a person actively participates at the screen and deliberately starts the bot, for example in direct customer contact. Unattended RPA is suited for processes without a need for supervision that are meant to run in the background, but requires a fully logged-off target machine and a fixed screen resolution so that UI recognition works reliably.

Can a process with many exceptions still be automated?

Partially. If most cases follow the same pattern and only a small share deviates, you automate the standard path and route exceptions to a human via escalation. If, on the other hand, the exception rate is 30 percent or more, it's usually worth simplifying or more clearly defining the process before automating it.