Power Automate

Power Automate Desktop – UI elements break after minor UI changes (WindowNotFoundException)

(0) Share

Report

Posted on by PS-23031332-0

Hi Team,

I am facing a recurring issue while automating a desktop application using Power Automate Desktop.

Scenario:

I have created a flow that interacts with a Windows desktop application.
Whenever a new version of the application is released, I update the version number in the Windows element selector, and the script works fine initially.
However, after some time (even without major changes), the script suddenly fails from the very first step.

Problem:

The flow fails with a generic error stating that it cannot locate the element.
Even if there is only a minor UI change, the entire flow breaks.
When I try to “relocate” an element, it only fixes that specific step.
For the next step, the same issue occurs again.
Eventually, I end up having to re-capture/relocate almost every element, which is equivalent to recreating the whole flow.

Error Details:

Correlation Id: 1abf6b8b-1bea-46f9-9908-30d5645856bb

Exception of type 'Microsoft.Flow.RPA.Desktop.Modules.UIAutomation.Common.Exceptions.WindowNotFoundException' was thrown.: Microsoft.Flow.RPA.Desktop.Modules.SDK.Extended.Exceptions.InternalActionException: Click failed (failed to get window) ---> Microsoft.Flow.RPA.Desktop.Modules.UIAutomation.Common.Exceptions.WindowNotFoundException: Exception of type 'Microsoft.Flow.RPA.Desktop.Modules.UIAutomation.Common.Exceptions.WindowNotFoundException' was thrown.

at Microsoft.Flow.RPA.Desktop.UIAutomation.Core.Abstractions.ServiceRouter1.Invoke(MethodInfo targetMethod, Object[] args)

at generatedProxy_2.ClickElementInWindow(UIRuntimeElement, Int32, Int32, MouseClickTypeEnum, RectangleEdgePointEnum)

at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)

at System.Reflection.MethodBaseInvoker.InvokeWithManyArgs(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)

--- End of remote exception stack trace ---

at Microsoft.Flow.RPA.Desktop.Modules.UIAutomation.Common.Proxy.RemoteAutomationRuntimeProxy.Invoke(MethodInfo targetMethod, Object[] args)

--- End of stack trace from previous location where exception was thrown ---

at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()

at System.Reflection.DispatchProxyGenerator.Invoke(Object[] args)

at generatedProxy_2.ClickElementInWindow(UIRuntimeElement , Int32 , Int32 , MouseClickTypeEnum , RectangleEdgePointEnum )

at Microsoft.Flow.RPA.Desktop.Modules.UIAutomation.Actions.ClickElementInWindow.<Execute>b__26_1(IAutomationRuntimeProxy r, UIRuntimeElement e)

at Microsoft.Flow.RPA.Desktop.Modules.UIAutomation.Common.UIAutomationActionBase.PerformAutomation(Action2 action, UIControl control, Boolean logAction)

at Microsoft.Flow.RPA.Desktop.Modules.UIAutomation.Actions.ClickElementInWindow.Execute(ActionContext context)

--- End of inner exception stack trace ---

at Microsoft.Flow.RPA.Desktop.Modules.UIAutomation.Actions.ClickElementInWindow.Execute(ActionContext context)

at Microsoft.Flow.RPA.Desktop.Robin.Engine.Execution.ActionRunner.Run(IActionStatement statement, Dictionary2 inputArguments, Dictionary2 outputArguments)

Questions:

Is there a more stable way to define selectors so that flows don’t break frequently?

How can I avoid re-capturing all elements after each version/UI change?

Are there best practices to make selectors more resilient?

Additional Context:

This issue has occurred multiple times (4–5 times so far).

Any guidance or best practices would be really helpful.

Thanks in advance!

Categories:

Power Automate Desktop

I have the same question (0)

All responses (2)

Answers (0)

Sort by

Suggested answer

Sunil Kumar Pashikanti 2,318 Moderator on at

Like
a
(0)

Report
Copy link

Link copied!

Hi @PS-23031332-0,

This issue happens because Power Automate Desktop (PAD) selectors are extremely sensitive to UI changes. Even small updates in the application (like version numbers, window handles, or regenerated automation IDs) make the original selector invalid, which leads to WindowNotFoundException. Relocating fixes only one element at a time because the whole UI Automation tree has changed.

To make your automation stable, you need to build resilient selectors, not rely on the default captured ones.

Best practices:

Remove volatile selector properties (version numbers, dynamic IDs, process IDs).
Use “contains” or “starts with” instead of exact matches.
Build hierarchical (ancestor‑based) selectors rather than direct element selectors.
Use keyboard navigation instead of mouse clicks where possible.
For unstable UIs (Electron/WPF), use image recognition for elements that change often.
Use fallback selectors or multiple selector variants stored in variables.

With these changes, your selectors will survive most UI updates, and you won’t need to recapture every element again.

Ref:
https://sunilpashikanti.com/resources/#-ui-selector-stability-playbook-2026-edition
https://learn.microsoft.com/en-us/power-automate/desktop-flows/build-custom-selectors

https://www.hubsite365.com/en-ww/crm-pages/ui-elements-and-selectors-in-power-automate-desktop-full-tutorial.htm

✅ If this answer helped resolve your issue, please mark it as Accepted so it can help others with the same problem.
👍 Feel free to Like the post if you found it useful.

Was this reply helpful? Yes No
PS-23031332-0 2 on at

Like
a
(0)

Report
Copy link

Link copied!
Hi,

Thanks for the detailed explanation.

In my case, the flow was initially created using the record feature, so the selectors were auto-generated by Power Automate Desktop.

I did try improving them by:

Removing some dynamic properties

Using “contains” instead of exact matches

However, the issue still persists. The flow sometimes fails from the very first step with WindowNotFoundException, and even after updating selectors, I end up needing to relocate almost every element again.

It feels like the window/parent element itself becomes invalid, which then causes all child elements to fail.

Was this reply helpful? Yes No