Cloud flows in Power Automate are excellent at gluing modern services together. SharePoint to Teams, Outlook to Planner, Forms to a spreadsheet. The connector library is enormous and most of what an office worker needs already lives in it.
Then someone hands you the procurement system the finance team has been on since 2008, or the bespoke pricing tool that lives on a single workstation, or the Power BI Desktop file that has to be republished from a local data source. The connector library has nothing for any of them, and a ticket to build a custom connector will outlive everyone involved.
Power Automate Desktop is the answer to that gap. It automates what the user does, not what the API exposes.
The mental model
Think of Power Automate Desktop as a second category of flow that lives alongside cloud flows, not under them. Cloud flows are API-first. They talk to services in the format the service expects, through authenticated connectors, with the speed and reliability that comes from never touching a screen.
Desktop flows are UI-first. They drive applications the same way a person does, through windows, buttons, fields, and menu items. If a human can do it with a mouse and keyboard, Power Automate Desktop can do it too. The trade-off is built into the model: it works on anything because it works the way humans work, and it breaks for the same reason.
The two are designed to work together. A cloud flow can trigger a desktop flow when a SharePoint file lands, the desktop flow does its UI work on the right machine, and the result comes back to the cloud flow for the rest of the process. The boundary matters - anything with a working API belongs in the cloud flow. Power Automate Desktop exists for the apps that don't give you one.
How a desktop flow is put together
The designer is sequential. Drag actions from the panel on the left, configure their inputs, and they run top to bottom. Three categories of action cover almost everything.
UI actions. Click this button, type into that field, select this menu item. Power Automate Desktop identifies targets through selectors, which is the part that breaks most often. A selector is a description of the element in the application's UI tree, and when that tree changes - a button moves, gets renamed, sits in a new dialog - the selector is no longer valid. Recording two selectors for each critical element (a primary and a fallback) is the difference between a flow that survives the next vendor update and one that doesn't.
Application actions. Open Excel, run an Excel macro, save the workbook. Most Office apps have direct actions that bypass the UI layer entirely, which makes them noticeably sturdier than equivalent click-by-click sequences. Reach for these first. Fall back to UI actions only when the application gives you no other choice.
Flow control. Variables, loops, conditionals, error handling. Same logic patterns as code, just with a visual surface. Variables move data between actions: read a value from one window's field, store it, type it into a different window's field. The vocabulary stops there. Everything else is composition.
A real scenario
The most common Power Automate Desktop job in practice: open a legacy report system, navigate to a specific report, export it as CSV or PDF, save it with today's date, and either upload it to SharePoint or send it to a distribution list.
That flow is a date action, a launch-application action, a sequence of UI actions for the export menus, a save action with the date interpolated into the filename, and either a send-email action or a handoff back to a cloud flow. Ten or fifteen actions in total. No code. The full build is in tomorrow's Build It.
What it doesn't do
The biggest failure modes are predictable and worth naming up front.
Brittle to UI changes. Selectors break when the target app updates. A flow that has run quietly for six months will fail the morning after a vendor pushes a new version. Recording a backup selector for every critical element, and adding error handling at the points where selectors live, is the difference between a flow that survives and one that needs constant repair.
Single-machine concurrency. Attended desktop flows run on the user's machine and lock the screen while they run. Two flows can't sensibly share a machine. Unattended flows need a separate host that stays on, signed in, and licensed for unattended execution.
Licence-gated for production. Unattended flows require a per-user-per-machine Premium licence, and the Power Automate Process plan exists for organisations running bots at scale. Pricing this up before building anything is worth the ten minutes it takes.
No magic for web apps. Power Automate Desktop has a browser automation layer that works on Edge and Chrome, but a proper API call to the web app is almost always better, and Playwright is almost always more reliable when no API exists. Reach for Power Automate Desktop's browser actions when nothing else is available, not as the default.
Where it sits in the toolbox
Power Automate Desktop is the third tier of M365 automation. Office Scripts handles browser-based Excel work. Cloud flows handle service-to-service work through APIs. Power Automate Desktop handles everything else - the apps that don't fit either of the first two. Most automations a citizen developer builds will sit in one of the first two tiers. Power Automate Desktop comes out when nothing else can reach.
Frequently Asked Questions
Does Power Automate Desktop run on Mac?
No. Power Automate Desktop is Windows-only. The runtime depends on the Windows UI Automation framework and the desktop integration that comes with it. If your fleet is mixed, the practical answer is to run desktop flows from a Windows host that's accessible to the people who need to trigger them, or move the work to a cloud flow when a connector exists.
Do I need a Premium licence to use it?
Attended desktop flows are included with most M365 plans that already include Power Automate. Unattended desktop flows - the kind that run on a schedule without anyone signed in - need a Power Automate Premium licence per machine. The Power Automate Process plan covers fleets of bots and is the right answer at scale.
What's the difference between Power Automate Desktop and cloud Power Automate?
Cloud flows talk to services through APIs and run in Microsoft's infrastructure. Desktop flows drive applications through their UI and run on a specific Windows machine. Both are accessed through the same Power Automate portal, both can trigger each other, and both share the same governance model. They're not competing products, they're two halves of the same automation platform.
Is RPA the same thing as Power Automate Desktop?
RPA (robotic process automation) is the category. Power Automate Desktop is Microsoft's product in that category. UiPath, Automation Anywhere, and Blue Prism are the other major players. The underlying idea - automate the UI when the API isn't available - is the same across all of them. Power Automate Desktop's advantage is that it ships inside the M365 stack and integrates natively with cloud flows.
Can a cloud flow trigger a desktop flow?
Yes, and this is the recommended pattern for anything production-grade. The cloud flow handles the schedule, the trigger, and the integration with the rest of the M365 stack, and calls the desktop flow only for the part of the job that needs UI automation. Both halves are visible in run history together, which makes debugging considerably easier than treating them as separate systems.
Where to go from here
For the practical end-to-end build, see Build a Power Automate Desktop flow that exports a report and emails it daily at 7am (May 26 Build It). For the quick scheduling tip that pairs with this whole pattern, see Schedule a desktop flow without leaving Power Automate (May 23 Click Bait).
