The choice between attended and unattended RPA determines your entire deployment architecture — not just a setting you pick at the end. Learn how to evaluate your process, register and configure machines, set up machine groups for scale, and avoid the session management pitfalls that break unattended bots in production.
Picture this: your accounts payable team manually logs into three different vendor portals every morning, downloads invoices as PDFs, cross-references them against a spreadsheet of purchase orders, and then enters the matching data into your ERP system. It takes two people about three hours a day. You've already built the desktop flow logic — it can navigate the portals, read the PDFs, validate the data, and enter it into the ERP without a single keystroke. The question now isn't can you automate it, it's how should it run?
Should a bot wake up at 2 AM and do the whole thing silently while no one's watching? Or should the flow assist a human who's already sitting at their desk, handling the exceptions that need judgment while the bot handles the repetition? That architectural decision — attended versus unattended — is one of the most consequential choices in any RPA deployment. Get it wrong and you'll either have expensive infrastructure sitting idle or a bot that breaks whenever someone accidentally moves a window.
By the end of this lesson, you'll understand the fundamental differences between attended and unattended run modes, know how to evaluate which one fits a given process, and be able to configure machine connections, machine groups, and run settings in Power Automate to deploy both modes in production.
What you'll learn:
This lesson assumes you're already comfortable building desktop flows in Power Automate Desktop. You should understand the basics of recording and running flows locally, and you should have at least a passing familiarity with cloud flows in Power Automate. If you're still getting your bearings, start with Getting Started with Power Automate Desktop: Installing, Recording, and Running Your First Desktop Flow before continuing here. You should also understand how cloud flows trigger desktop flows — concepts covered in Triggering Desktop Flows from Cloud Flows: Passing Inputs and Returning Outputs.
You'll need:
Before diving into configuration, let's establish a precise understanding of what differentiates attended and unattended execution — because the terminology gets muddied in vendor marketing and forum discussions.
Attended RPA means the automation runs on a machine where a human user is actively logged in and present. The bot shares the desktop session with the person. Attended flows are typically triggered manually — the user clicks a button in the Power Automate Desktop app, uses a cloud flow triggered from a Teams message, or invokes the flow from a Power Apps canvas app. Critically, the bot runs in the foreground on the logged-in user's session. The user can watch it happen, can be prompted for input mid-flow, and is expected to be available to handle exceptions.
Unattended RPA means the automation runs on a machine without a human present — often on a server or a dedicated VM. The bot logs into Windows on its own (or works within an existing locked session depending on configuration), performs its work, and logs off. Nobody is watching. The machine might be physically in a data center. Unattended flows are triggered by cloud flow schedules, events, or queue items — never by a human clicking "run."
The practical consequences of this distinction are deep:
| Dimension | Attended | Unattended |
|---|---|---|
| Session ownership | Human user's active session | Bot-managed session (auto-login) |
| Trigger | Human action or manual trigger | Scheduled or event-driven cloud flow |
| User interaction | Can pause for human input | Must be fully autonomous |
| Machine requirement | Any Windows PC the user works on | Dedicated machine or VM (often headless) |
| License cost | Lower (included in base per-user) | Higher (requires unattended add-on) |
| Scalability | 1 flow per machine at a time | Multiple bots via machine groups |
| Appropriate for | Processes with judgment steps | Fully defined, exception-free processes |
Key insight
Attended automation is about augmenting a human. Unattended automation is about replacing a human task entirely. Choosing the wrong mode doesn't just cause technical problems — it creates operational ones. An "unattended" process that actually has frequent exceptions will generate a backlog of failures with no one around to fix them.
The single most useful question you can ask is: "Can this process run to completion without a human making any decisions?"
If the answer is reliably yes — even accounting for edge cases — unattended is viable. If there are judgment calls, data validation steps that require human eyes, or frequent exceptions that can't be handled programmatically, attended is the safer choice.
Here's a more detailed evaluation framework:
Tip
Many mature RPA deployments use both modes in tandem. An unattended bot processes the bulk of a workload overnight, then a morning attended flow lets a human review an exception report and handle the items the bot couldn't resolve. Design for this hybrid from the beginning rather than retrofitting it later.
Regardless of which run mode you choose, your machine needs to be registered in the Power Automate portal before any cloud flow can trigger a desktop flow on it. This registration is what creates the connection between the cloud and your Windows machine.
When you install Power Automate Desktop and sign in, the application creates a secure connection between that machine and your Power Automate environment. Behind the scenes, the machine registers itself in Microsoft's infrastructure and begins polling for run requests. When a cloud flow triggers a desktop flow, it sends the run request to the cloud, which routes it down to the registered machine through this secure channel.
To register your machine:
The machine entry in the portal shows you the machine name, the current connection status, which environment it's registered to, and (for unattended) the credentials configured for auto-login.
Warning
A machine only shows as "Connected" when the Power Automate Desktop application is running and the machine is powered on and network-accessible. For unattended scenarios, this means the machine must always be running with Power Automate Desktop active — a common source of failed runs is a VM that got rebooted and whose Power Automate Desktop service didn't restart automatically. Set it to launch on startup.
For unattended flows, you need to tell Power Automate what credentials to use to log into the machine (or unlock the session). In the Power Automate portal, navigate to your machine's settings and look for the Credentials section.
You have two options:
Windows credentials: A local Windows account or domain account that has the rights to log into the machine. Power Automate will use these credentials to create or unlock a Windows session when a flow run is triggered. This is the most common approach for machines joined to an Active Directory domain.
Connection credentials (for already-logged-in sessions): In some configurations — particularly with Windows Server and Remote Desktop Services — you pre-configure a session and the bot runs within it without logging in fresh each time.
For production unattended deployments, store your Windows credentials using the Credentials feature in the Power Automate portal rather than hardcoding them anywhere. This integrates with Azure Key Vault, keeping secrets out of flow definitions. The complete guide to secrets management with Azure Key Vault explains this integration in depth — it's worth reading before you push unattended flows to production.
A single machine can only run one unattended desktop flow at a time. If your process generates more concurrent work than one bot can handle, you need machine groups — a pool of machines that Power Automate can distribute work across.
In the Power Automate portal, navigate to Monitor > Machine groups and click New machine group. Give it a descriptive name that reflects the workload — something like "InvoiceProcessing-Prod" rather than "BotGroup1". You'll add individual machines to the group, and Power Automate will automatically load-balance run requests across whichever machines in the group are available and connected.
When a cloud flow triggers a desktop flow and targets a machine group, Power Automate queues the request and dispatches it to the next available machine. If all machines are busy, the request waits in the queue until one frees up. You can configure the maximum queue duration — how long a request will wait before timing out — in the machine group settings.
How many machines do you need? A rough formula:
Required machines = ceil(Peak concurrent runs × Average run duration in minutes / 60)
So if your invoice processing flow takes 4 minutes per run and you need to process 90 invoices within a 1-hour window:
Peak concurrent runs needed = 90 runs / (60 min / 4 min per run) = 6 machines
Round up, add one for redundancy, and you're looking at 7 machines in your group. In practice, you'll also want to account for the time flows spend queuing and for occasional machine unavailability.
Note
Azure Virtual Machines are the most common infrastructure choice for unattended machine groups. You can use Azure VM Scale Sets with Power Automate, though this requires additional setup. For most enterprise deployments, a fixed pool of VMs with auto-start policies is simpler and more predictable than elastic scaling.
Use an individual machine connection when:
Use a machine group when:
Once your machine or machine group is registered, you connect it to a cloud flow that triggers your desktop flow. This is where the run mode choice becomes explicit in the configuration.
Navigate to the cloud flow that will trigger your desktop flow. In the Run a flow built with Power Automate Desktop action, you'll configure three critical settings:
The action has a Run Mode field with two options: Attended and Unattended.
Attended: The flow will run in the foreground of the currently logged-in user's session. If no user is logged in, the run will fail. The machine connection should point to an individual machine (not a machine group, unless all machines in the group will have active user sessions, which is unusual).
Unattended: The flow will run in a background session, using the credentials configured on the machine. Power Automate will create a new Windows session or work in an existing disconnected one.
This is where you select which machine or machine group to run on. The dropdown shows you all registered machines and machine groups in your environment. For attended flows, select the specific machine belonging to the user who will be logged in. For unattended flows, select a machine group (or a specific dedicated machine).
Warning
Don't point an attended flow at a machine group in most cases. Machine groups are designed for queuing unattended work. If you configure an attended flow to target a machine group and the machine that has an active user session isn't the one the queue selects, your run will fail with a "no active user session" error.
Finally, select the specific desktop flow to run. You can also pass input variables here — data from the cloud flow trigger (like an invoice ID from a SharePoint list or an order number from a Dataverse record) becomes an input parameter to the desktop flow. This is the pattern described in detail in Triggering Desktop Flows from Cloud Flows: Passing Inputs and Returning Outputs.
Session management is where unattended RPA most often breaks down in practice. Let's walk through what actually happens when an unattended run is triggered and where things can go wrong.
The machine is on but no one's registered it correctly. If the bot account's password has expired or been changed without updating the machine credentials in the portal, the auto-login step fails and every run fails silently at step 4.
Another session is blocking. On Windows 10/11, only one interactive session can run at a time. If an IT administrator is remotely connected to your bot machine, the bot can't create its session. Use Windows Server with Remote Desktop Services configured for multiple sessions, or ensure no humans ever log into bot machines interactively.
The target application doesn't exist in the bot's session. The bot might use an application that's installed for all users on the machine, but some applications store their configuration (like the currently connected server) in the user profile. If the bot user's profile has never been configured for that application, the bot will open it to a blank or error state. Test your flows by actually logging in as the bot service account and running them manually at least once before putting them into unattended production.
Screen resolution mismatch. Selectors that work fine on a 1920x1080 monitor sometimes fail in a remote desktop session with a different resolution because button positions shift. Set a consistent resolution in your bot VM's Remote Desktop settings and design your selectors to use control properties rather than pixel coordinates. The selector guide covers this in depth.
Tip
Create a dedicated Windows service account for your unattended bots — something like svc-rpa-invoicing@yourcompany.com. Grant it only the permissions it needs (principle of least privilege). Test the entire flow by RDP-ing into the machine as that service account before configuring it for unattended. If it works interactively as the service account, it'll work unattended.
Your error handling strategy needs to match your run mode. Attended and unattended failures look very different operationally.
When an attended flow fails, the user is right there. A reasonable strategy is:
The user's presence is a safety net. You don't need to handle every conceivable exception programmatically — the human can make judgment calls.
When an unattended flow fails at 3 AM, nobody's watching. Your error handling needs to be completely self-sufficient:
The error handling guide for desktop flows covers the full toolkit of On Block Error, retry policies, and recovery screenshots. Apply all of it for unattended flows.
Well-structured desktop flows can be deployed in either mode with minimal changes. The key is to isolate the mode-specific behavior (like user prompts) from the core processing logic using subflows.
A production invoice processing flow might look like this:
Main flow:
├── SubFlow: Initialize (set variables, connect to apps)
├── SubFlow: GetWorkQueue (read items from SharePoint list or Dataverse)
├── Loop through work items:
│ ├── SubFlow: ProcessInvoice (navigate portal, extract data, validate)
│ ├── SubFlow: WriteToERP (enter data into ERP)
│ └── SubFlow: UpdateStatus (mark item complete or failed in queue)
└── SubFlow: Cleanup (close applications, log summary)
Every subflow is purely functional and mode-agnostic. The only difference between attended and unattended deployment is how the flow is triggered and what runs at the top of Main — either a user kicks it off (attended) or a scheduled cloud flow does (unattended).
This architecture also lets you build and reuse subflows across multiple desktop flows, which pays dividends as your automation portfolio grows. The ERP writing subflow you build for invoice processing might be reusable in your purchase order flow with minor modifications.
Let's walk through configuring the same desktop flow for both attended and unattended deployment. We'll use an invoice processing scenario: the flow reads unprocessed invoice records from a SharePoint list, opens a vendor portal, downloads the invoice PDF, and writes the data to an ERP system.
Ensure your desktop flow accepts input variables:
InvoiceID (text) — the ID of the invoice to processVendorPortalURL (text) — the portal URL to navigate toAnd returns output variables:
ProcessingResult (text) — "Success" or "Failed"ErrorMessage (text) — empty on success, error detail on failureIf you need to pass multiple invoice records, consider passing a JSON string and parsing it inside the flow using the data table and variable handling patterns.
For attended testing:
For unattended production:
ProcessingResult output: if "Success," update the SharePoint item status to "Processed." If "Failed," update status to "Review Required" and send a Teams notification with the ErrorMessage.Tip
Process invoices sequentially within a single cloud flow run (loop with Apply to Each, concurrency = 1) rather than firing simultaneous desktop flow invocations unless you've sized your machine group for parallel execution. Parallel processing is faster but harder to debug when things go wrong.
If the run fails, check the desktop flow run details for error messages. The most common first-time failure is credential misconfiguration on the machine.
The Power Automate Desktop application is not running on the target machine. For unattended machines, configure Power Automate Desktop (or the underlying Windows service, UIFlowService) to start automatically with Windows. In Services (services.msc), find "Power Automate Desktop" service and set it to Automatic startup.
An application opened a modal dialog or authentication prompt that the flow doesn't handle. In unattended mode this is catastrophic — the flow will sit indefinitely. Add explicit checks after launching applications: use a "Wait for element" action with a timeout, and handle the timeout with an error block. Check for common dialogs (update notifications, certificate warnings, "do you want to save?") and dismiss them programmatically.
Nine times out of ten, this is an environment difference between your development user account and the bot service account. Check: application configuration stored in the user profile, mapped network drives (service accounts often don't have drive letters mapped), Windows environment variables referenced in the flow, and application licensing tied to the interactive user's identity.
Some applications serve different interfaces based on user roles or browser state. The bot service account might have different permissions than your test account. Verify the service account has identical application permissions to the users it's replacing, and test by actually logging in as the service account and opening the application.
Your machine group is undersized for the volume. Either add more machines to the group or redesign the flow to process multiple items per run (batch processing inside the desktop flow rather than one cloud flow invocation per item). Batching is significantly more efficient — one flow invocation that processes 50 invoices is much faster than 50 flow invocations that each process one.
Warning
Power Automate imposes a maximum queue time for desktop flow runs (24 hours by default). If your machine group is undersized and the queue backs up past this limit, older run requests will expire and be marked as failed without ever executing. Monitor your queue depth in the machine group dashboard and set up alerts if it grows beyond a threshold.
Choosing between attended and unattended RPA is an architectural decision, not just a setting. Attended mode is the right choice when humans need to remain in the loop — for judgment-dependent tasks, compliance-sensitive processes, or workflows where user context matters. Unattended mode is for fully autonomous, high-volume processes that can run without supervision.
The technical configuration follows naturally from that decision: attended flows point to individual user machines and run in foreground sessions; unattended flows target machine groups, use service account credentials, and run in background sessions managed by Power Automate Desktop.
The operational disciplines that separate reliable production bots from fragile demos are the same in both modes: robust error handling, structured logging, careful selector design, and testing under realistic conditions (as the actual service account, with real data). The difference is that attended flows have a human safety net while unattended flows need to handle everything themselves.
Here's where to go next: