Attended and unattended RPA are not two versions of the same thing. They are architecturally different, commercially different, and operationally different. Choosing between them is not a technical preference; it is a programme decision with direct consequences for licensing cost, infrastructure requirements, and what can realistically be automated.

The reason organisations get this wrong is not a lack of information. It is that the decision is usually made too early, on the basis of a process description rather than a verified understanding of how that process actually runs. A process that looks unattended on a whiteboard is frequently attended in practice. A process that looks simple may have an exception rate that makes unattended automation economically unjustifiable.

This article sets out what attended and unattended RPA actually mean in Power Automate Desktop, where each model is the right answer, and the questions that should drive the decision before any licensing is purchased or infrastructure is scoped.

What the Terms Actually Mean

Attended RPA

Attended automation runs on a user's machine, triggered by the user, and operates alongside them in the same session. The bot assists: it can handle repetitive data entry, transfer information between systems, or execute a defined sequence of steps while the user handles the judgement calls, exceptions, and approvals that the automation cannot.

In Power Automate Desktop, attended flows run within a user's active Windows session. They require that user to be logged in, and they cannot run when the machine is locked or the user is away. The user triggers the flow, either manually or via a Power Automate cloud flow that calls the desktop flow on demand.

Attended automation is the right model for any process where a human needs to be in the loop: reviewing outputs, handling exceptions, providing input that varies case by case, or approving actions before they are committed.

Unattended RPA

Unattended automation runs without a logged-in user, on a schedule or triggered by an event, on a dedicated machine or hosted infrastructure. The bot operates independently: it logs into systems, processes data, executes transactions, and completes its work with no human in the loop.

In Power Automate Desktop, unattended flows run on a machine runner, either a physical or virtual machine configured as an unattended bot, or a Microsoft-hosted machine provisioned on demand. The machine does not need a logged-in user. Flows can run overnight, during peak processing windows, or continuously throughout the day.

Unattended automation is the right model for high-volume, rules-based processes with low exception rates, predictable inputs, and no requirement for human judgement during execution.

The most common misclassification

A process is described as 'just data entry, no decisions needed' and is scoped as unattended. In testing, it emerges that 15 percent of records have exceptions requiring human review. The unattended bot has no way to handle them. The programme either adds attended handling for exceptions (doubling the architecture) or discards 15 percent of the process value. Neither outcome was in the original scope.

How the Licensing Differs

The licensing difference between attended and unattended is significant and frequently underestimated at scoping stage.

The per-user Premium licence, which covers attended automation, is a flat monthly cost per named user. For a team of twenty people each using attended bots to assist with their own work, twenty Premium licences cover the requirement.

Unattended RPA requires a Process licence, which is significantly more expensive than per-user Premium, plus an Unattended RPA add-on per concurrent bot. If the programme needs three bots running simultaneously overnight, that is three Process licences and three Unattended add-ons. If those bots run on Microsoft-hosted machines rather than on-premises infrastructure, there is an additional hosted machine add-on cost per bot per month.

The economics shift dramatically depending on concurrency. A single unattended bot running one process at a time has a very different cost profile from ten bots running ten simultaneous processes. Organisations that size their licensing around process count rather than concurrent bot requirements consistently either overspend or under-provision.

The Infrastructure Difference

Attended automation requires no dedicated infrastructure. It runs on the user's existing machine, within their existing Windows session. The only prerequisite is the Power Automate Desktop application and the correct licence.

Unattended automation requires a machine to run on. That machine must be available 24 hours a day, must not be used for other high-demand work that could create resource contention, and must have network access to every system the bot needs to interact with. In organisations with on-premises systems, this also means an On-Premises Data Gateway if the flow reads from or writes to data sources that are not publicly accessible.

Microsoft-hosted machines remove the infrastructure management burden: Microsoft provisions a Windows VM on demand when the flow runs and deprovisions it afterwards. The trade-off is that hosted machines do not persist between runs. Any application that needs to be pre-installed, pre-configured, or pre-authenticated cannot use a hosted machine unless that setup is scripted as part of the flow itself.

The infrastructure decision needs to be made before licensing is purchased. An organisation that buys unattended licences assuming hosted machines will work, then discovers mid-programme that their target application cannot be installed on a clean VM, has a significant problem that costs both time and money to resolve.

The Questions That Should Drive the Decision

The attended vs unattended decision should be made per process, not as a programme-wide choice. The following questions determine the right model for each candidate process.

1. Does the process require any human input, judgement, or approval during execution? If yes, attended or a hybrid model is required.

2. What is the exception rate, and what happens to exceptions? High exception rates make unattended architectures more complex and expensive. If exceptions require human review, the unattended bot must have a mechanism to route them out.

3. Does the process need to run outside business hours, or faster than a human can trigger it? If yes, unattended is required.

4. What is the volume, and does it require concurrent execution? High-volume processes that must complete within a defined window may require multiple concurrent bots, which directly drives the Process licence count.

5. What systems does the process interact with? On-premises systems, VPN-dependent applications, or systems requiring specific local installations may rule out Microsoft-hosted machines and require on-premises bot infrastructure.

6. What is the credential model? Unattended bots need service accounts with appropriate system access. Those accounts need to be created, configured, and maintained. In organisations with strict Active Directory policies, this is a change control item with lead time.

A practical guide: three process types and the right model for each

High volume, rules-based, low exceptions, runs overnight: unattended, on-premises runner or hosted machine depending on application requirements.

Human-assisted data entry or validation: assisted with exceptions, same workstation: attended, per-user Premium licence.

Mixed process: automated bulk, human review of exceptions: hybrid architecture, unattended for the bulk run, attended trigger for exception handling queue.

Where This Sits in the VE3 Readiness Framework

The Power Automate Licensing domain and the Hosted Machines domain of the VE3 Power Platform Readiness Framework cover both the licensing decision and the infrastructure prerequisites for RPA specifically. The framework asks whether attended, unattended, or both models are in scope, what the target concurrency requirement is, whether hosted or on-premises runners are preferred, and what the credential and service account requirements are.

These questions exist in the framework because they are consistently answered late, and because the cost of answering them late is consistently higher than the cost of answering them at the outset. A programme that has verified its RPA model, its concurrency requirement, and its infrastructure approach before licensing is purchased is a programme that does not discover those dependencies mid-build.

About VE3

VE3 is a global technology and consulting partner specialising in enterprise AI, data, and digital transformation. A Microsoft Solutions Partner across multiple solution areas, the company works with public sector bodies, Blue Light organisations, and enterprise clients across financial services, healthcare, energy and utilities, and manufacturing. To discuss Power Platform, RPA, or the VE3 Readiness Framework, contact your VE3 representative.