Desktop flow

What is a desktop flow?

A desktop flow is an automated set of steps that carries out work inside Windows programs and websites. You build it in Power Automate for desktop, the design and run application, using actions for clicking, typing, files, Excel, browsers, text, and other tasks. The flow you save is the concrete process; one machine can hold many of them for different jobs.

Desktop flows are the robotic process automation side of Power Automate. They often drive the same interface a person would, which is what lets them take over work in older applications that offer no API or connector. When a proper connection exists, a cloud flow is usually the better choice; a desktop flow earns its place where the screen is the only way in.

How a desktop flow works

Actions run in a set order and pass data through variables. A flow can fetch a file path, open an application, enter values, and keep a result in a new variable. Conditions and loops steer the run: a loop can work through every row of an Excel file, and a condition can push records without a customer number onto a separate error list.

UI elements identify buttons, fields, and other on-screen items by their properties, so the flow looks for the element rather than clicking blindly at a fixed position. A selector describes which properties are used to find it. The recorder can turn actions you perform into steps and UI elements, which gives you a first draft. Treat it as a draft: remove needless steps, replace fixed waits with checks where you can, and add explicit error handling.

A worked example

An organisation receives a CSV file of new prices. The old stock package has no import function and no API. A desktop flow reads each row, finds the product in the application, and enters the new price. For every row it first checks that the product exists; if it does not, it writes the line to an exceptions file. After saving, it reads the displayed price back and only marks the row as done when the two match.

At the end the flow writes counts and errors to a log, and a cloud flow can pick that log up and send a summary to the process owner. That keeps the screen automation to the one part with no technical connection. One detail matters if the flow stops halfway: the next run has to recognise the rows already processed, or the same change can land twice or on the wrong record.

Attended and unattended desktop flows

An attended desktop flow runs while a person is present and signed in. They start it or feed it input, and can judge exceptions as they come up, which suits assistance during case work. An unattended desktop flow runs with no one at the machine, on a managed device, started from the cloud or on a schedule. This needs the right licence and a machine set up for it.

Unattended does not mean unmanaged. Application updates, expired passwords, pop-ups, and changed screens can still break a run, so monitoring and a recovery procedure stay necessary. If you would rather not manage physical machines at all, Microsoft-hosted machines can run the same flows on infrastructure in Azure.

Desktop flow versus cloud flow and API

A cloud flow reaches online services through connectors and APIs. That interface is meant for software and tends to change less often than a screen, and a cloud flow can run without an interactive session. A desktop flow uses the visible interface: useful when an API is missing, but slower and more fragile. Do not reach for one just because recording looks quicker than understanding an existing connector. For large volumes, transactions, and processes that must react fast, an API integration is usually the better fit. A desktop flow suits bounded tasks with predictable screens and a manageable volume.

What to watch out for with desktop flows

Use specific UI elements and avoid screen coordinates. Wait for an element or window to appear rather than pausing a fixed number of seconds, and confirm the expected result after an important action. Add error handling around each risky step, and keep enough context to investigate a failure without logging passwords or personal data you do not need. Take screenshots only where your security policy allows.

Split large flows into subflows with one clear job, give variables and actions readable names, and note which version of the target software you tested against. Run the flow again after updates to Windows, browsers, and that software, since a change on screen is exactly what an interface-driven automation notices first. Assign an owner and write down how a failed run is resumed. A desktop flow is only useful when the process stays under control even when something goes wrong.