Cloud flow vs desktop flow

What it does

Two ways to make the same task happen. A cloud flow talks to a system through its API using a connector; a desktop flow drives the system's user interface with simulated keyboard and mouse input. Same outcome on a good day, wildly different cost and fragility profile over three years.

Key facts

Microsoft's own ordering of automation methods is connector first, then custom connector, then HTTP, then browser automation, then desktop application automation. The first three are described as not easily affected by system changes; the last two are.
Desktop flows need a registered machine. Registration requires a Power Automate Premium user licence, and that stays true whether the flow later runs attended or unattended.
A Premium user licence includes one attended bot on the user's registered machine. Unattended running needs a Process licence allocated to the machine, or a Hosted Process licence for a hosted machine or hosted machine group.
Attended runs need an active signed-in session; unattended runs need the user signed out or the session disconnected. Don't mix attended and unattended work on the same machine or machine group.
Cloud flows trigger desktop flows, not the other way round. The desktop flow is a step inside the orchestration, and the connection user running it needs a licence with desktop flow entitlement.
Browser automation sits in the middle: it's UI automation, so it's still selector-dependent, but a basic grasp of HTML and CSS makes selectors far more durable than blind coordinate clicking.
Cloud flow actions bill against Power Platform request allocations. Desktop flow runs additionally consume a bot — one desktop flow at a time per unattended bot, so parallel throughput is bought, not configured.

When to use / skip

The rule is simple and you should say it out loud in every discovery session: use a desktop flow only when there is no API. Not "no connector" — no API. If the vendor has a REST endpoint and nobody's built a connector, a custom connector or an HTTP action is a day's work and it survives the next release of the target system. A desktop flow does not.

There are three honest exceptions. First, where the API exists but is commercially gated behind a licence tier the client won't buy — UI automation is then the cheaper path and you should say why in writing. Second, where the API can't reproduce a piece of business logic that only lives in the UI layer, which happens with older ERP screens more often than vendors admit. Third, where you're buying time: a desktop flow as a deliberate stopgap while an integration is built, with a date attached. Everything else is someone avoiding a conversation with an integration team.

Configuration decisions

Does the target system have an API at all, and if so, what's actually blocking you from using it — capability, licensing, or organisational access?
Attended or unattended, and therefore which licence and which machine estate. This decision drives cost more than anything else in the design.
Physical machines, self-hosted VMs, or hosted machine groups. Hosted removes the infrastructure conversation and adds a licence line.
How many desktop flows need to run at the same time. That number is the number of unattended bots you're buying, and clients consistently guess low.
Which parts of the process stay in the cloud flow. Keep orchestration, branching, logging and approvals in the cloud flow and let the desktop flow do the narrowest possible UI job.

Gotchas

Desktop flows break on things nobody classes as a change: a browser update, a new consent banner, a field moved twenty pixels, a slow morning where the screen wasn't ready. Cloud flows don't have failure modes shaped like that.
The Premium licence's attended bot tempts people into building an "unattended" automation on someone's laptop. It works in UAT and falls over the first time the user locks their screen or takes leave.
Credentials for unattended runs live somewhere. That somewhere needs a real answer from security before build, not after.
A desktop flow that runs for twenty minutes ties up a bot for twenty minutes. Two of those and a nightly batch and you've quietly run out of capacity.
Screen resolution, display scaling and multi-monitor setups change selector behaviour. Machines that run desktop flows should be treated as fixed configuration, not as normal desktops.

Consultant notes

Price the maintenance, not just the build. A desktop flow carries an ongoing break-fix cost that a connector-based flow doesn't, and if you don't put a number on it the client will assume it's zero.
Insist on a named owner for each desktop flow before go-live. UI automation degrades continuously and needs someone whose job it is to notice.
When a client asks for RPA by name, run the API check anyway. A surprising proportion of "we need RPA" requests turn out to be a system with a perfectly good API that nobody in the room had authority to request access to.
Where you do build UI automation, log aggressively and screenshot on failure. Diagnosing a desktop flow from run history alone is miserable.

Worth rechecking whenever a target application announces a UI refresh — that's the release that breaks the selectors