Desktop Flows and RPA

Cloud flows automate systems that expose a connector or API, but a huge share of real business work still happens inside legacy Windows executables, Citrix-published apps, and websites with no supported API at all. Desktop flows close that gap: built with the free Power Automate Desktop (PAD) application, they use robotic process automation (RPA) to record and replay mouse clicks, keystrokes, and UI element interactions exactly as a human performed them. A recorder captures each interaction as a discrete action referencing a UI element 'selector', and the resulting flow can be triggered from a cloud flow, run on a schedule, or launched from the PAD console, making it the automation layer of last resort when no proper integration exists.

The PAD recorder is only the starting point; once a sequence is captured, every action lands as an editable step in the flow designer, so you can insert Wait actions, If/Else branches, loops over an Excel range, or variables without re-recording from scratch. Actions like 'Populate text field', 'Click', and 'Get text from window' each store a selector describing the target control's position in the UI element tree, and the designer's selector editor lets you swap a brittle, index-based selector for one anchored to a stable attribute such as an automation ID or accessible name. Because desktop flows run against real windows, they can also invoke non-UI actions in the same sequence, such as launching an executable, running a PowerShell script, or manipulating files, which lets a single flow blend legacy screen automation with modern scripting in one linear sequence.

Some environments, most commonly Citrix-published applications, remote desktop sessions, and mainframe green-screen terminals, expose no accessible UI tree at all, so PAD falls back to image recognition and OCR-based actions like 'Click on Image' or 'Extract text from window using OCR'. These actions compare a saved reference image against the live screen at runtime and click the matched location, or read pixels through an OCR engine (PAD ships with a built-in OCR engine and can call the Azure AI Vision OCR engine for higher accuracy) when no selector is available. Image-based automation is inherently more fragile than selector-based automation because it depends on exact screen resolution, DPI scaling, color rendering, and window position, so flows built this way should pin the target window's size and position at the start of the sequence and re-verify the reference images whenever the remote environment changes appearance.

Because desktop flows interact with real, sometimes slow or unpredictable UIs, every action should be wrapped in error handling: PAD's 'On Block Error' setting lets you configure a per-action retry count and interval, or route failures to a labeled error-handling block that logs the error, captures a screenshot with 'Take screenshot', and either retries the parent action or gracefully ends the run. A common resilience pattern combines explicit 'Wait for element' or 'Wait for window' actions ahead of a Click, rather than fixed Wait Time delays, so the flow proceeds the instant a control becomes available instead of guessing a static duration that may be too short on a slow VM or wastefully long on a fast one. Flows launched from a cloud flow can also return structured output variables back to the caller on both success and failure paths, letting the parent cloud flow branch on the desktop flow's outcome and trigger a Teams alert or ticket creation if the unattended run failed.