Attended vs Unattended Flows

Analogy categoryAnalogies

Attended vs Unattended: The Core Distinction

An attended desktop flow runs inside a user's own interactive Windows session, typically launched manually from the Power Automate Desktop console, a Power Apps button, or a keyboard shortcut, and it's designed to assist a human who's present at the keyboard, often pausing for input or handing control back partway through. An unattended desktop flow, by contrast, runs on a machine with nobody logged in interactively, triggered from a cloud flow on a schedule or an external event (like a new item in a SharePoint list), executing entirely autonomously against a dedicated Windows machine or virtual machine registered specifically for that purpose. The technical mechanism differs meaningfully too: unattended execution needs a way to actually log into Windows and unlock the session programmatically without a human physically present, which is why unattended machines are registered into a 'machine group' in the Power Platform admin center with stored credentials, rather than simply having PAD installed on someone's laptop.

🏏

Cricket analogy: Like a batting coach standing beside a player during a live net session, adjusting technique in real time, an attended flow runs alongside a present user who can interact with it mid-run.

Machine Groups, Gateways, and Scheduling

Unattended machines must be registered in a machine group inside the Power Platform admin center, and each machine's runtime needs the PAD service to be running under either a dedicated service account with stored, encrypted credentials, or via Azure Virtual Desktop/hosted machine integration for cloud-provisioned unattended capacity; this is what actually lets the RPA process log into a locked Windows session without a human typing a password. Because machine groups pool multiple registered machines, a cloud flow calling an unattended desktop flow can queue runs against whichever machine in the group is free, and Power Automate handles the queuing, letting you scale unattended throughput horizontally by simply adding more machines to the group rather than redesigning the flow. Scheduling for unattended runs is typically driven from the cloud flow side, using a Recurrence trigger or an event trigger like 'When an item is created', rather than from within PAD itself, keeping the orchestration logic (when and how often to run) separate from the automation logic (what the desktop flow actually does).

🏏

Cricket analogy: Like a franchise's pool of net bowlers where the next available bowler is assigned to whichever batter needs practice, a machine group queues an unattended run to whichever registered machine is free.

Licensing and Governance

Attended RPA is available through the standard per-user Power Automate premium license, since it runs in a licensed user's own session and the user is the one triggering and interacting with it, whereas unattended RPA requires an additional, separately purchased unattended RPA add-on per bot/machine, reflecting that it consumes dedicated compute capacity around the clock rather than borrowing a human's already-licensed session. Governance for unattended flows also carries more weight because a failure or a compromised credential can run at 2 a.m. with nobody watching, so admins typically apply tighter controls: dedicated service accounts with least-privilege access scoped only to what the automation needs, DLP (data loss prevention) policies restricting which connectors an unattended environment can combine, and monitoring/alerting wired to notify a team channel on failed unattended runs rather than relying on a user noticing something went wrong. Environments intended for unattended production automation are also commonly separated from personal or default environments specifically so admins can apply these stricter policies without also restricting every user's ad hoc attended automation.

🏏

Cricket analogy: Like a franchise needing a separate contract for a bowling machine used in unattended practice sessions versus a coach who's already on staff and simply uses the nets during work hours, unattended RPA needs its own dedicated license.

text

// Cloud flow orchestrating an unattended desktop flow run

Trigger: Recurrence  Interval: 1, Frequency: Day, Time: 02:00 UTC
Action: Run a flow built with Power Automate for desktop
         Desktop flow: 'Nightly Invoice Reconciliation'
         Connection: Machine Group = 'Finance-Unattended-Pool'
         Run mode: Unattended
Condition: outputs('Run_a_flow_built_with_Power_Automate_for_desktop')?['status'] eq 'Failed'
  If yes -> Post message in Teams channel 'RPA-Alerts'
  If no  -> Log success to Dataverse table 'AutomationRuns'

A single unattended machine can only run one desktop flow at a time by default, so throughput scales by registering more machines into the machine group, either physical/virtual machines on-premises behind a gateway or cloud-hosted machines provisioned through the Power Platform, not by trying to run multiple unattended flows concurrently on one box.

Because unattended flows execute with nobody watching, storing the service account credential insecurely, or granting it broader permissions than the automation actually needs, turns a single compromised or misconfigured unattended bot into a much larger blast radius than a mistake in an attended flow a user would likely notice mid-run; always apply least-privilege scoping and route failure alerts to a monitored channel.

Attended flows run inside a present user's own interactive session; unattended flows run autonomously with nobody logged in.
Unattended execution requires machines registered into a machine group with a service account able to unlock the session programmatically.
Machine groups pool multiple machines so unattended throughput scales horizontally by adding machines, not by overloading one machine.
Scheduling for unattended runs is typically driven from the calling cloud flow (Recurrence/event trigger), not from within PAD itself.
Attended RPA uses the standard per-user premium license; unattended RPA requires a separate, dedicated add-on per bot/machine.
Unattended environments warrant stricter governance: least-privilege service accounts, DLP policies, and monitored failure alerting.
A compromised or over-permissioned unattended credential has a larger blast radius since nobody is watching the run in real time.