Attended vs Unattended Flows

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.

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).

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.