Power Automate Desktop and RPA

How Power Automate Desktop automates legacy applications with RPA — attended vs unattended, machine groups, AI Builder integration, and where to use it.

Updated 2026-04-24

Power Automate Desktop (PAD) is Microsoft's Robotic Process Automation (RPA) tool — the bit of the Power Automate stack that drives the user interface of other applications, including legacy desktop apps, terminal emulators, ancient web apps, and anything else without a usable API. For Dynamics 365 customers, PAD is the bridge to systems that haven't joined the API era yet.

Attended vs unattended.

  • Attended RPA — the bot runs on a user's own desktop while the user is logged in. The user triggers it (or it triggers from a Power Automate cloud flow), watches it work, and can intervene. The right pattern for assistant bots: a salesperson clicks a button, the bot opens a legacy CRM, copies opportunity data, and pastes it into Dynamics 365. Available with most Power Automate paid plans.

  • Unattended RPA — the bot runs autonomously on a dedicated machine or VM, without a user logged in. Triggered by Power Automate cloud flows on a schedule or event. The right pattern for batch processes: a nightly job logs in to a legacy ERP, extracts a report, and uploads it to Dynamics 365. Requires a Power Automate unattended RPA add-on licence per bot, plus dedicated infrastructure.

Machine groups. For unattended scenarios at scale, machine groups pool multiple machines so flows can scale horizontally. Cloud flows queue work, and any available machine in the group picks it up. Microsoft also offers a managed hosted machines option where Microsoft provisions and manages the bot VMs.

Building flows. PAD's flow designer is desktop-based — a Windows application installed on the machine where flows are authored. Actions are drag-and-drop: open browser, click element, send keys, extract text, read Excel, OCR image, call AI Builder model, branch on condition, loop. The designer captures UI elements visually — click on a button in the target app, and PAD records the selector for replay.

UI selectors. The fragile part of any RPA. PAD selectors can be DOM (for web), UI Automation (for Win32 / WPF / UWP), image-based (last resort), or coordinates (avoid). Changes to the target application's UI break selectors. Robust RPA design uses the most stable selector available and tolerates layout drift where possible.

AI Builder integration. PAD calls AI Builder models inline — extract text from an image, classify a document, predict a value — combining classic RPA with AI-driven processing.

Where to use it.

  • Legacy ERP / CRM that has no usable API.
  • AS/400 green-screen apps still running in some manufacturing and finance shops.
  • Excel-heavy back-office processes that can't be redesigned.
  • Bridge during a system migration: temporarily double-key into both old and new systems during cutover.

Where not to use it. Any time a real API exists. RPA is brittle; integrations through APIs are stable. PAD is the last resort, not the first.

Operating discipline. Build runbooks: what to do when a bot fails. Monitor bot run history daily in early life. Plan for the inevitable target-application UI change that breaks the bot. Budget for ongoing maintenance — RPA without maintenance is failed RPA.

Licensing reality. Attended is bundled with most paid Power Automate plans; unattended requires a per-bot add-on plus infrastructure (Microsoft-hosted or self-hosted). Costs add up at scale; do the maths against the manual effort being replaced.

Related guides