Why Does My Power Automate Desktop Flow Keep Breaking?

UI element selector failures after portal updates, SAP GUI struggles, Conditional Access blocking unattended flows, per-step latency, and the licensing maze of attended vs hosted machines: a Power Automate Desktop diagnostic with routing table and cost math.

First, a disambiguation that search engines keep muddling: this page is about Power Automate Desktop, Microsoft's RPA product, the one that drives applications and browser sessions through their UI on a Windows machine. Power Automate Cloud flows, the connector-based, API-calling kind, are a different product with different failure modes, and if a connector covers your workflow, a cloud flow avoids this page entirely. The failures below belong to desktop flows, because desktop flows automate screens, and screens change.

Platform-agnostic version: why RPA bots keep breaking. Full arc: the anchor diagnostic.

Failure-to-fix routing table

UI element failures: "my desktop flow can't find the element since the site updated"

Power Automate Desktop captures UI elements into an element repository: DOM attributes for web targets, UI Automation tree properties for desktop apps. Every captured element is a bet that those attributes hold still. When the portal ships a redesign, renames a class, or rebuilds a form, the bet loses: the flow throws "UI element not found," or, quieter and worse, a loosened selector matches a different element and the flow clicks it.

The repair loop: open the flow, re-capture the failing elements against the updated page, tighten or loosen selector attributes, and re-test the whole flow, because a redesign rarely moves just one element. Budget 4 to 16 dev-hours per meaningful break, and expect 1 to 3 a year per actively developed portal. PAD's selector editor gives you manual control that helps at repair time; nothing in it changes the frequency, because the frequency is set by the portal's release calendar, not yours. The structural analysis is in the RPA overview; the escape is an integration with no UI reference, which is the trade Supergood vs Power Automate walks through.

SAP GUI and legacy ERP: "the flow dies somewhere in the SAP screens"

PAD against SAP GUI and similar legacy interfaces is screen-scraping a stateful terminal UI: screens that repaint mid-read, grids that render as bitmaps, modal dialogs that appear based on server state your flow can't see. SAP's own scripting mode helps when Basis will enable it; longer waits and screenshot-based fallbacks patch the rest. This is the part of the estate where UI automation is sometimes genuinely the only option, and where it's also at its most fragile. Worth separating honestly: a mainframe emulator with no network layer is RPA's legitimate home turf, but a web portal wrapped around the same ERP has a backend its frontend calls, and that layer is integrable.

Conditional Access: "the unattended flow can't sign in anymore"

The distinctly Microsoft failure mode. Your unattended desktop flow signs into a Windows session with stored credentials, and somewhere in the tenant, a Conditional Access policy update starts flagging exactly that pattern: unattended sign-in, datacenter VM, no MFA response, risk score assigned. The flow that ran nightly for a year now fails at authentication, and the fix conversation happens with the security team, not in PAD.

Exemptions, trusted locations, and excluded service accounts work, and every one of them is a carve-out a security review will eventually question, because the carve-out is real attack surface. The trend is one-directional: tenants tighten. Automation that authenticates like a human will keep colliding with policies built to challenge exactly that. An integration layer with real service accounts, where authentication is programmatic by design rather than by exemption, moves with the trend instead of negotiating against it. That's how Supergood handles portal authentication, MFA included.

Latency and throughput: "the flows can't keep up"

Desktop flows execute at UI speed: each action waits for the application or page to render, 2 to 10 seconds per step, ~30 seconds for a typical login-navigate-submit flow. The throughput cap is structural: one desktop flow runs per machine session, so parallelism means hosted machines or a machine group, which is a licensing decision.

Desktop flows are also slow relative to their own cloud siblings: a cloud flow calling a connector completes in seconds because it skips the screen entirely, which is the whole point. Where no connector exists, the comparison becomes desktop flow vs managed API, and the unit economics from the true cost of browser automation past 10,000 calls a month apply directly.

Licensing: "we ran out of unattended capacity"

PAD's licensing confuses enough buyers to deserve its own failure mode. Attended RPA comes with the per-user plan: a human watching. Unattended runs require hosted machines or unattended add-ons, capacity is finite, and when it's exhausted, runs queue or fail with a capacity error, usually discovered the week volume grew. The remedy is buying more capacity, which is the same per-bot scaling law every RPA platform runs on: throughput priced in machines, not in work done. Per-call API economics don't have a run-capacity error.

The 12-month worked example

One portal workflow at 10,000 runs a month. Assumptions stated: two drift breaks at 10 dev-hours, one Conditional Access incident at 8 dev-hours, 2 dev-hours a month of babysitting, one hosted machine running ~83 hours a month.

The decision rule: if a Power Automate connector or official API covers the workflow, use a cloud flow, that's Microsoft's own architecture telling you the same thing this series does. Where the portal has no API and no connector, Supergood generates and maintains one: REST and MCP endpoints from the portal's own backend traffic, callable from a cloud flow like any connector, with no desktop machine, no element repository, and no Conditional Access exemption. The comparison is in Supergood vs Power Automate.

Related reading

• Why your enterprise automation keeps breaking — the full failure arc
• Why does my RPA bot keep breaking? — the platform-agnostic view
• Why does my UiPath bot keep breaking? — the UiPath sibling
• Supergood vs Power Automate — the direct comparison
• The true cost of browser automation past 10,000 calls a month — the cost model

FAQ

Why does my Power Automate Desktop flow keep failing? UI element selector failure, most often: the element repository references the target's UI tree, and portal redesigns invalidate it. Re-capture elements, budget 4 to 16 dev-hours per break, 1 to 3 breaks a year per active portal.

What's the difference between Power Automate Desktop and Cloud? Cloud flows call APIs through connectors and never touch a screen; Desktop is Microsoft's RPA, driving UIs on a Windows machine. The failure modes here belong to Desktop. If a connector covers the workflow, use a cloud flow.

Why does Power Automate break when the website changes? Desktop flows target the page's DOM through captured selectors; a redesign changes the DOM and the selectors stop matching. The reference is to layout, and layout changes 1 to 3 times a year on an active portal.

Why are unattended flows blocked by Conditional Access? Stored-credential sign-ins from datacenter VMs are exactly what Conditional Access flags. Exemptions work until security review; the durable fix is programmatic service-account auth at the integration layer.

Why is Power Automate Desktop so slow? Each action waits on a render, 2 to 10 seconds per step, one flow per machine session. At 10,000 monthly runs that's ~83 hours of flow time; the API equivalent totals under 3 hours.