UI automation selector

What is a UI automation selector?

A UI automation selector is the description an automation uses to find one specific control in a desktop application or web page. The target might be a window, a text box, a button, a table row or any other on-screen element.

A selector is built from a hierarchy and a set of attributes. A child element sits under a window and a panel, say, and carries a name, a control type or an automation ID. At run time the tool looks for an element that fits the description. If nothing matches, the step fails; if several things match, it may act on the wrong one.

Selectors are the backbone of desktop automation in tools like Power Automate, part of the Microsoft Power Platform, and of RPA more broadly. Getting them precise is most of what makes a flow reliable.

Desktop and web selectors

Desktop selectors can use Windows UI Automation, the modern accessibility layer that most current Windows applications expose. Older software sometimes only exposes Microsoft Active Accessibility, an earlier layer; MSAA selectors can still reach those controls but give you a less detailed structure to work with.

Web selectors use the page structure, the DOM, and its attributes instead. The browser window and the page content inside it are different layers, so pick the element type that matches the action you want to take.

Reading a selector

A selector usually describes a path from the root down to the target. Each level narrows the search using properties such as the process, the window title, a class, a role, a name or an ID.

Not every available attribute belongs in the selector. A temporary window handle or a randomly generated ID makes it too specific, so it breaks the next time the application runs. Going the other way, matching on control type Button alone is usually too broad. A good selector is just specific enough to hit the one element you mean and nothing else.

Handling attributes that change

Window titles often contain a case number or a date. Where the platform supports it, use wildcards, regular expressions or variables to match the part that stays the same, and keep the flexible part tied to a known pattern. A wildcard that matches any button at all makes the flow unsafe.

Text-based selectors can be stable when labels are permanent, but they break the moment the application is translated. An automation ID is usually the sturdier choice when the application provides one consistently.

Using more than one selector

A single element can hold several selectors tried in order: if the first does not work, the run time falls back to the next. Alternatives are useful across different application versions, or when UIA is available in one build and only MSAA in another. They should all aim at the same element, never at different functional targets. Test each selector on its own and inside the full flow, and switch off an old alternative once it starts producing broad, wrong matches.

Example: the Save button

An order window has a Save button in its toolbar, and a dialog inside it has its own Save button. A selector that matches on the word Save alone finds both.

The stable version names the order window, the correct toolbar and the button's automation ID, and the test should return exactly one match. When the dialog is open, the flow waits for it to close first, or anchors to a specific part of the screen, so it does not accidentally hit the first Save button it happens to find in the top left.

Selectors versus coordinates and images

A selector uses the structure of the interface, so it usually keeps working when an element shifts by a few pixels. A coordinate click only hits the same screen position, wherever the element has moved to. Image and OCR based actions are useful when an application exposes no elements at all, but they are more sensitive to scale, theme and any visual change. Prefer selectors where you can, and write down why a visual fallback was needed when you have to use one.

What to watch out for with UI automation selectors

Test selectors against different records, window sizes, user roles and language settings, and check the zero, one and many match cases each time. Use time-outs and wait for the right screen state, because a selector can be correct while the element has simply not loaded yet.

A broad selector can hit the wrong record or button, so add a functional check before anything irreversible and confirm the result afterwards. Do not lean on a selector to get around authorisation: the running identity and the application still own access control. Treat selector changes like any other code change and review, test, version and deploy them through the agreed lifecycle.