Setting Up Unattended RPA in Power Automate

Unattended desktop flows run without a screen, without a keyboard, and without anyone watching. A machine logs itself in, executes the flow, and then logs back out again, in the middle of the night or whenever a new job appears in the queue. For processes like nightly invoice ingestion, transferring order data between two systems, or generating recurring reports, this is exactly the operating mode that pays off.

Until some time ago, the path there ran through an on-premises gateway. Microsoft has since replaced that path: gateways for desktop flows are no longer supported, and instead each machine registers directly with the Power Automate service. This article shows which steps are actually required for setup, from the license through machine registration to the first unattended run.

What sets unattended desktop flows apart from attended ones

In an attended flow, someone sits at the computer and starts the automation manually, often with prompts or inputs along the way. An unattended flow, by contrast, runs completely without human involvement: Power Automate signs in to the machine using stored credentials, runs the flow, and then signs out again. According to the Microsoft documentation on running unattended desktop flows, Power Automate creates a remote desktop session on the target machine for this; a connection to the console session is not supported for unattended runs. The screen stays locked for the entire execution, so no one is watching and no one can accidentally interfere.

Important for planning: Windows 10 and Windows 11 refuse unattended runs as soon as an active user session exists, even if it's locked. You should therefore avoid mixing attended and unattended automation on the same machine, and plan separate machines for each instead.

Prerequisites: license, role, and permissions

For unattended automation you need the Power Automate process plan, as described in the documentation on purchasing and assigning Power Automate licenses. Assignment works in two stages: first, an administrator assigns the process license to an environment in the Power Platform admin center, then a license is consumed per machine that is meant to run unattended. If more than one unattended flow runs simultaneously on the same machine, each additional parallel run needs its own license.

For the actual registration, the Environment Maker role is sufficient; anyone who wants to restrict registration to specific people can instead assign the Desktop Flow machine owner role. Without one of these roles, no machine can be connected to an environment.

Step 1: Register the machine

Registration today runs via direct connectivity, no longer via a gateway. According to the guide on managing machines, it's enough to install Power Automate for Desktop version 2.8.73.21119 or later and enable the option to install the runtime app. After starting the Power Automate machine runtime and signing in, the machine registers itself automatically in the currently selected environment; if it isn't registered yet, Power Automate directly asks for the desired environment.

A few points are worth a second look before you go live:

• Windows 10 Home and Windows 11 Home devices do not support direct connectivity.
• You must not clone a virtual machine after installing the runtime app, otherwise the registration gets mixed up.
• If you perform a PC reset, you lose the registration and have to sign the machine in again.
• Anyone still using old gateway connections can find the affected desktop flow connections under Data > Gateways and switch them there step by step to Direct to machine.

Step 2: Assign process capacity as an unattended bot

A registered machine still cannot run unattended flows until capacity has been assigned to it. According to the documentation on process capacity, a machine only becomes a so-called unattended bot once process capacity has been assigned. On the machine's detail page, use the Unattended bots slider to set how many parallel unattended runs the machine may process at the same time, and save the setting. Each assigned bot can take on exactly one run at a time; for three parallel runs you therefore need three bots and correspondingly three process licenses.

How many bots a single machine can support at most depends on the operating system; for some Windows Server variants the upper limit is ten. Alternatively, capacity can also be assigned automatically: as soon as an unattended run is pending, Power Automate then independently assigns a bot, which then remains on the machine until manually released.

Step 3: Set the cloud flow to unattended mode

Only now does the actual flow come into play. You create or edit a cloud flow, set up a desktop flow connection within it, and select unattended mode when triggering the desktop flow. Power Automate then handles sign-in, execution, and sign-out automatically based on the credentials stored in the connection.

Two pitfalls come up most often here in practice:

• The stored user needs permissions for a remote desktop session on the target machine, typically membership in the Remote Desktop Users group. If it's missing, the run fails with a permissions error.
• When signing in via Microsoft Entra ID with a certificate, or with a username and password over NLA, additional steps are needed, such as enabling Entra authentication for RDP for the relevant app ID and hiding the consent dialog for the target device group. Without this authorization, the run fails with the error `MSEntraRemoteDesktopAppConsentRequired`.

Step 4: Set screen resolution and session behavior

The default resolution of a remote desktop session often differs from the resolution the flow was originally recorded at. In unattended operation, this quickly leads to elements that can't be found, or clicks landing in the wrong place. Using the flow properties of a desktop flow, you can therefore set a fixed screen resolution for unattended runs; if the flow calls further subflows, this resolution then applies to all of them.

In addition, under Monitor > Machines > Settings you can enable the Reuse sessions for unattended runs feature. This keeps the Windows session intact after a run (just locked), instead of being rebuilt completely from scratch, which noticeably speeds up consecutive runs. If you later add a machine to a machine group, it automatically adopts that group's settings; if you remove it again, the last valid values are retained.

Operation, limits, and maintenance mode

For installations or maintenance work on a machine, there's a dedicated switch: Maintenance mode stops new assignments for a single machine or an entire machine group, without cancelling runs that are already in progress. If the machine runs alone, new jobs land in the queue; if it's part of a group, another active machine takes over.

For planning larger setups, a few fixed limits help: a machine group holds a maximum of 50 machines, and according to the documentation a desktop flow may sit in the queue for a maximum of twelve hours before it's marked as failed. For sporadic failures, it's also worth checking the machine's session status: a locked or disconnected session of the same user reliably blocks any further unattended run until it's actively ended.

Anyone who doesn't want to maintain their own VMs long-term can switch to hosted machines or hosted machine groups, which Microsoft provisions directly in Azure and scales automatically as needed. For most mid-sized setups, however, a single registered machine is entirely sufficient at first, before scaling is even worthwhile. Which variant fits your own process volume is best assessed based on the specific flow, for example as part of a Power Automate consulting engagement. You retain full control at all times over which machine takes on which process and when it's available for it.

Frequently asked questions

Do I still need a gateway for unattended desktop flows?

No. Gateways for desktop flows are no longer supported. Instead, machines register directly with the cloud via the Power Automate machine runtime as soon as you sign in there. Existing gateway connections should be switched to the Direct to machine connection type.

How many unattended runs can a machine execute at the same time?

Exactly as many as it has been assigned in process capacity. Each assigned unattended bot takes on one run at a time; the upper limit per machine is up to ten bots, depending on the operating system. For more parallel runs you need correspondingly more process licenses.

Why does my unattended flow fail despite correct credentials?

The most common reason is an already active, even if locked, Windows session on the target machine, since unattended runs require a machine that all users are signed out of. Also check whether the stored user is a member of the Remote Desktop Users group and whether the password is still valid.

Can I run attended and unattended on the same machine at the same time?

Microsoft explicitly advises against this, because attended automation requires an active session, while unattended automation requires a signed-out or disconnected session. In practice, the two operating modes block each other; it's cleaner to use a dedicated machine per operating mode.

Is a hosted machine group worthwhile compared to your own VM?

That depends on volume. A single registered machine is entirely sufficient for many processes and can be set up quickly. Only once utilization fluctuates heavily or several processes need to run in parallel does a hosted machine group pay off, because it automatically scales bots up and down as needed.