The Recorder in Power Automate Desktop: Capabilities and Honest Limits

Few features lower the barrier to entry in Power Automate Desktop as much as the Recorder. Instead of dragging actions one by one from the actions list and filling in parameters by hand, you simply click your way through the process you want to automate, and the Recorder translates every mouse and keyboard movement into a ready-made flow action. For recurring click sequences in familiar programs, this is often the fastest way to a first working draft.

Just as important, though, is the honest second half of the story: the Recorder is not a tool that reliably understands every interface, and it does not replace post-processing. This article shows how the Recorder works technically, what it covers beyond simple clicks, and where it hits clear limits according to Microsoft's own documentation, especially with complex or unusually built user interfaces.

What the Recorder captures and how it does it

You'll find the Recorder directly in the Flow Designer toolbar. Clicking Recorder opens the recording window, and clicking Record starts the capture. From that moment on, the Recorder tracks your mouse and keyboard activity relative to the respective UI elements and converts each action into a step. During recording, a text marker briefly shows the message “Waiting for action” until the click has actually been captured and inserted, a small but practical signal that you shouldn't click through too quickly.

Right-clicking an element also opens a context menu with the actions available for that element, such as setting a dropdown value or extracting text. Once you finish the recording with Done, Power Automate automatically converts the recorded steps into desktop flow actions and stores all elements used in the UI elements pane so you can reuse them later. You'll find details in the Microsoft documentation on recording desktop flows.

UIA and MSAA: two capture modes for different programs

Not every Windows application provides the same quality of accessibility information, which is why the Recorder offers two capture modes. UI Automation (UIA) is the modern framework recommended by Microsoft and works especially reliably with applications built using WPF, WinForms, or UWP; it provides more detailed element information and a more stable hierarchy. Microsoft Active Accessibility (MSAA) is older and steps in where applications don't provide UIA elements, such as classic Win32 or VB6 programs. You select the appropriate mode via the “Recording mode” menu in the Recorder, depending on which application you're currently automating.

More than just clicks: what else the Recorder covers

The Recorder isn't limited to simple mouse clicks; it specifically covers a whole range of recurring UI patterns:

• Dropdown lists: As soon as you select a dropdown list, the Recorder opens its own screen where you set the desired value, or multiple values for multi-select. At runtime, Power Automate selects this value automatically.
• Date and color pickers: For HTML input fields of type date, datetime-local, month, time, or week, as well as color pickers, the Recorder opens a text field where you enter the desired value in the appropriate format.
• Input Method Editors (IME): For languages that can't be typed directly on a QWERTY keyboard, you can right-click “Fill text field” to enter text via an IME.
• Launching a browser three ways: You can start a new browser specifically via the menu in the Recorder (Edge, Chrome, Firefox, Internet Explorer), begin recording in an already open browser, or open the browser manually via a shortcut, which the Recorder then records as its own UI automation action.

Image-based recording: the Recorder for difficult applications

Some applications don't expose their accessibility API at all, or come with other technical hurdles, so the regular Recorder can't capture any actions whatsoever. For exactly this case, Power Automate offers image-based recording: instead of detecting UI elements via selectors, this mode works with image recognition and optical character recognition (OCR). Clicking an element automatically creates an image snippet with an editable name, and via “Extract text from image” you can additionally select a text area as well as a stable anchor area nearby, from which the text is read using the Tesseract OCR engine.

The honest limits: where the Recorder reaches its limits

This is exactly where it's worth looking at the known issues documented by Microsoft itself, because they show that the Recorder deliberately makes trade-offs and is no miracle solution.

Documented limitations of the Recorder

• Steps from the Windows Start menu or the taskbar may not be fully recorded, and Microsoft explicitly offers no workaround for this.
• In flows recorded via image, the click may land in the wrong place at runtime; as a fix, Microsoft recommends lowering the tolerance value of the automatically generated “Move mouse to image” action in the advanced settings.
• The popup window for “Extract text from image” can hide behind the popup of the actual application; right-clicking elsewhere on the screen helps here.
• Keystrokes sent to a maximized RDP window via image-based recording sometimes don't arrive at all, which is why Microsoft recommends shrinking the RDP window so it doesn't fill the entire screen.
• Drag-and-drop is only partially supported: the Recorder reliably captures actions like moving a window or resizing it, but currently not the “Drag and drop UI element of a window” action.

When the Recorder or Element Picker can't see anything at all

It gets even more fundamental when the Recorder or the Element Picker can't capture an application at all. According to the Microsoft troubleshooting guide for UI automation, there are two typical causes for this. First, disruptive background processes like the Microsoft Accessory Center or DesktopBridge can completely block UI automation; here it helps to end the processes and disable them permanently. Second, and considerably harder to work around, some desktop applications use their own UI frameworks or rendering methods that aren't compatible with the standard accessibility APIs that Power Automate builds on. For the Recorder, these elements then simply remain invisible.

Microsoft names four workarounds for this case: move mouse to image, move mouse to text on screen via OCR, have the Recorder work with hardcoded coordinates, or combine mouse and click actions directly via fixed coordinates. It's important to note the explicit warning in the documentation here: for coordinate-based solutions to work reliably, screen resolution, DPI settings, and scaling must exactly match the development configuration at runtime, and even small changes to the application's interface can render the automation step unusable. Microsoft therefore explicitly recommends thoroughly testing such flows on every target machine before they go into production.

An image as a lifeline, with its own limits

For individual UI elements, you can additionally store an image as a fallback mechanism that automatically kicks in when the regular selector can no longer find an element at runtime. This safety-net mechanism also has clear limits: it isn't supported for data extraction and web data extraction, nor for actions like “If window contains” or “Wait for web page content” if the condition “Contains text” or “Does not contain text” is configured there. And anyone who opens and saves a flow with an image fallback in a Power Automate Desktop version up to and including v2.44 permanently loses the image selector; according to Microsoft, recovery is no longer possible in that case.

Recorder as a skeleton, not a finished result

Microsoft puts it pleasantly plainly in its own documentation: the Recorder is meant to provide the basic framework of a flow; most recorded processes should subsequently be reworked to run reliably. Certain action types, such as conditions and loops, fundamentally cannot be recorded at all and must be added by hand afterward. This is exactly where a flow that works once in testing parts ways with one that still runs reliably months later.

Whether you use the Recorder yourself for first drafts or have an entire digital employee built on top of Power Automate, in the end you retain control over which clicks really stay automated, which selectors are robust enough for production use, and where an image fallback or an OCR solution poses more of a risk than a safeguard.

Frequently asked questions

Can the Recorder record any application?

No. By default, the Recorder only works with applications that expose their elements via UIA or MSAA. If an application doesn't expose its accessibility API at all, image-based recording steps in as a fallback, but even that sometimes fails completely with custom-rendered or heavily customized interfaces.

What's the difference between UIA and MSAA?

UIA is the more modern framework recommended by Microsoft, with more detailed element information, suitable for most current Windows applications. MSAA is older and is mainly needed for legacy software that doesn't provide UIA elements, such as classic VB6 or Win32 programs. Which mode fits depends solely on the target application, not on personal preference.

Why does the Recorder suddenly stop seeing elements?

It's usually one of two causes: disruptive background processes like the Microsoft Accessory Center or DesktopBridge, which can be ended, or a UI framework of the target application that isn't compatible with the standard accessibility APIs. In the second case, often only a coordinate- or image-based solution remains as a workaround.

Do I always have to rework a recorded flow?

In practice, almost always, and Microsoft says so itself. The Recorder provides a working basic framework, but conditions, loops, and more robust error handling can't be recorded and must be added manually afterward in the Flow Designer.

How reliable is image-based recording in production?

Only as reliable as the screen environment it runs in. Resolution, DPI settings, and scaling must exactly match the development environment at runtime, otherwise the click misses its target. Anyone using image-based steps in production should combine them specifically with an image fallback for individual elements and test on every target machine before rollout.