Attended vs unattended RPA in Power Automate Desktop

Power Automate Desktop (PAD) automates desktop applications via robotic process automation — driving Windows UIs, web browsers, terminal applications programmatically. Two execution modes shape how PAD runs: attended (with a user) and unattended (lights-out, no user). The choice has licensing, infrastructure, and operational implications.

Attended RPA. A user is present:

• User starts the automation; bot runs alongside.
• User may interact between bot steps.
• User sees and can intervene if needed.
• One execution per user session.

Unattended RPA. No user present:

• Bot runs on a dedicated machine.
• Scheduled or triggered automatically.
• Runs through a queue.
• Many automations across many machines possible.

Choosing between modes.

• Attended — for tasks where the user benefits (data lookup, form-fill assistance, side automation while doing other work). User-pace.
• Unattended — for tasks running outside user's day (overnight reports, weekend processing, scheduled tasks). Machine-pace.

Licensing.

• Attended — bundled in Power Automate per-user plans or per-bot.
• Unattended — separate Power Automate "unattended bot" SKU; per concurrent bot per machine.

Unattended is materially more expensive because it's running 24/7 capacity.

Machine management. Each unattended bot needs a Windows machine:

• Power Automate machine — Windows VM registered with the Power Automate service.
• Machine groups — pool of machines for load balancing.
• Connection persistence — agents stay connected to the cloud service.

For unattended at scale, machine fleet management becomes infrastructure work.

Setup for unattended.

1. Provision Windows VM with PAD agent installed.
2. Register the machine with Power Automate.
3. Configure user account that bot will run as.
4. Test connectivity to PAD cloud service.
5. Schedule or queue the desktop flow.

The VM runs continuously; bots execute as scheduled.

Power Automate desktop machine groups.

• Multiple machines pooled.
• Cloud service distributes work.
• Provides redundancy.
• Scales horizontally.

For organisations with high unattended bot volume, machine groups are essential.

Triggers for unattended.

• Scheduled — cron-style.
• Event-based — Dataverse event, SharePoint event, etc.
• Manual — admin triggers ad hoc.
• From cloud flow — Power Automate cloud flow invokes desktop flow.

The cloud flow → desktop flow pattern is the most common: orchestration in cloud, desktop bot for the UI work.

Bot account. Bot runs as a specific Windows user:

• Dedicated service account.
• Stored credentials.
• Permission to applications being automated.

The bot's permissions = the user's permissions; respect least-privilege.

Concurrency.

• One bot per machine at a time — typically; some scenarios allow parallel sessions.
• Multiple machines for parallelism.
• Queueing — work waits in queue; processed FIFO.

Comparison patterns.

• High-volume back-office — unattended scale.
• User-assistive — attended.
• Periodic batch — unattended scheduled.
• On-demand desktop tasks — attended on user trigger.

Reliability considerations.

• Application UI changes break bots.
• Windows updates can affect bot behaviour.
• Network blips disrupt unattended runs.

Bots in production need monitoring and recovery patterns.

Common pitfalls.

• Treating attended as unattended. Running long-running automations on user's machine; user productivity blocked.
• Bot account credentials in plain text. Security violation; use Key Vault references.
• No exception handling. Bot fails halfway; partial state.
• No idempotency. Re-running breaks data.
• Single bot for all work. Bottleneck; queue grows.
• No monitoring. Bot runs daily; one day fails; nobody notices for a week.

Production-grade RPA.

• Machine groups for redundancy.
• Monitoring dashboards.
• Alerting on failures.
• Idempotent bot design.
• Exception handling at every step.
• Documented runbooks for common failures.
• Periodic UI regression checks — automation tested when target apps update.

Reconciliation. After unattended runs:

• Did each scheduled run complete?
• Did each record process correctly?
• Are there discrepancies vs source system?

Bots can silently fail; reconciliation surfaces it.

RPA vs API. Always prefer API when possible:

• API more reliable than UI scraping.
• API faster.
• API less brittle to UI changes.

Use RPA when API isn't available — legacy applications, terminal-based systems, web apps without APIs.

Strategic positioning. Unattended RPA is genuine automation at scale; attended is user-assistive productivity. Both have places. The licensing and infrastructure for unattended is material; weigh against the labour savings. For high-volume, repetitive desktop tasks where no API exists, RPA pays back; for lower-volume or where APIs are available, alternatives often win. Plan capacity, monitoring, and process discipline before scaling RPA broadly. The technology works; the operational maturity around it is what determines success.