Power Automate Desktop RPA errors

Power Automate Desktop automates applications that have no API by driving the actual user interface — locating buttons, fields, and windows on screen and simulating clicks and keystrokes. Most desktop-flow failures trace back to that interface not looking or behaving exactly the way it did when the flow was recorded.

"Selector not found" / the flow can't locate a UI element

Symptom. A step that previously worked fails because the action can't find the button, field, or window it's supposed to interact with.

Cause. UI element selectors are tied to the specific properties (window title, control type, position in the element tree) captured at recording time; a target application update, a different screen resolution or DPI scaling setting, or even the target window opening in a slightly different state can all change those properties enough that the old selector no longer matches.

Fix. Re-record the selector against the current version of the application rather than assuming a small property edit will fix it, and prefer selectors built on stable identifiers (a control's name or automation ID) over ones built on screen position, which breaks with any layout change.

Prevention. Re-test desktop flows against the target application after any update to that application, the OS, or the display configuration of the machine the flow runs on — these are the three most common root causes and none of them are under the flow author's control.

An unattended run fails or produces no result, with nothing in the run history to explain why

Symptom. A flow scheduled to run unattended shows as failed, or simply produces no output, with a generic error that doesn't point at a specific step.

Cause. Unattended runs execute in a session with no one watching, so a dialog the flow doesn't expect (a Windows update prompt, an application's own "unsaved changes" dialog, a credential re-prompt) can silently block the whole automation until it times out, without ever reaching the step that would normally surface the real error.

Fix. Re-run the same flow attended (with the target machine's screen actually visible) to reproduce the block interactively, since the same environment issue that stalls it unattended is usually visible immediately when someone can see the screen.

Prevention. Build defensive handling for expected interruptions (a scheduled Windows update window, a known re-authentication prompt) directly into the flow, and schedule unattended runs outside known maintenance windows for the target machine.

"Machine is offline" or the machine never appears as available for unattended runs

Symptom. A machine registered for unattended automation shows as offline or unavailable in the Power Platform admin centre, even though the physical or virtual machine is running.

Cause. Unattended automation depends on the Power Automate Desktop machine-runtime service staying connected and the machine having an active, valid Windows sign-in session available to use — a machine that has gone to sleep, lost network connectivity, or lost its cached credentials for the unattended sign-in will show as unavailable even while technically powered on.

Fix. Confirm the machine's power and sleep settings prevent it from sleeping during scheduled run windows, and re-validate the unattended sign-in credentials registered for that machine, which can expire or be invalidated by an unrelated password change.

Prevention. Dedicate machines used for unattended automation to that purpose with power settings configured specifically for always-on availability, rather than sharing a general-purpose machine that also gets put to sleep by a user.

A flow that works on one machine fails identically-configured on another

Symptom. The same flow, deployed to two machines that are supposed to be identically configured, works on one and fails on the other.

Cause. "Identically configured" rarely means byte-for-byte identical — different installed application versions, different regional/locale settings (which change date and number formats a flow's data-extraction steps expect), or different display scaling are common, easy-to-miss differences between two machines that look the same at a glance.

Fix. Compare the specific application version, Windows regional settings, and display scaling between the two machines rather than assuming the environments are equivalent because they're provisioned from the same base image.

Prevention. Standardise and document the exact application versions and regional settings desktop-flow machines must run, and treat any drift from that baseline as a change that needs re-testing.

Where to go next

The broader choice between desktop flows and cloud flows is in Power Automate Desktop and RPA and attended vs unattended RPA; cloud-flow failure patterns are covered separately in Power Automate flow failures explained. Registering and provisioning the machines themselves — the step before any of the above can run — is machine management for Power Automate.