Cloud Flows vs Desktop Flows in Power Automate: How to Pick the Right One

Scenario: Monthly Order Processing With Both SaaS and Legacy Apps

You work in an operations team that processes customer orders.

Today:

• Orders arrive in a SharePoint list.
• Approvals happen in Teams.
• Final order data is pushed into:
  • An online ERP (SaaS) via its API.
  • A legacy Windows client app running on an on‑premises VM.

You want to automate the whole chain:

1. When a new order is added to SharePoint, send an approval in Teams.
2. If approved:
   • Update the SaaS ERP via API.
   • Enter the order into the legacy Windows client.

You could:

• Build a cloud flow that handles SharePoint + Teams + SaaS ERP.
• Build a desktop flow that drives the legacy Windows client UI.

The confusion: Power Automate shows “flow” everywhere, but cloud flows and desktop flows are not interchangeable. They run in different places, have different trigger models, and different licensing implications.

Let’s disentangle that.

What Cloud Flows Actually Are

Cloud flows (in the “Automated”, “Instant”, “Scheduled”, and “Business process” categories in Power Automate) run in the Power Automate service in Microsoft’s cloud.

Key characteristics:

• Execution location: In Microsoft’s cloud, not on your PC.
• Trigger types (depending on connectors and licence):
  • Event‑based (e.g. “When an item is created” in SharePoint).
  • Button / manual (Power Automate portal, mobile app, Power Apps, etc.).
  • Scheduled (recurrence every X minutes/hours/days).
  • Business process flows (Dataverse‑centric scenarios).
• Connectors:
  • Use REST/API‑based connectors (SharePoint, Teams, Outlook, Dataverse, many SaaS apps).
  • Also include on‑premises data via the on‑premises data gateway (SQL Server, file shares, etc.).
• State and reliability:
  • Run as server‑side jobs; they’re not tied to whether a user’s PC is on.
  • Have built‑in retry and error handling options at action level.

In the scenario:

• The cloud flow is the right tool for:
  • Listening to SharePoint item creation.
  • Sending Teams approval cards.
  • Calling the SaaS ERP API.

Cloud flows cannot directly click buttons in a desktop app. They can only talk to things that expose APIs, connectors, or services reachable over the network.

What Desktop Flows Actually Are

Desktop flows are built in Power Automate for desktop and run via the Power Automate for desktop runtime and/or attended/unattended RPA infrastructure.

Key characteristics:

• Execution location:
  • On a Windows machine with Power Automate for desktop installed.
  • That machine can be:
    • Your local workstation (attended, user present).
    • A VM or physical server (attended or unattended, depending on setup and licence).
• Automation capabilities:
  • UI automation for Windows desktop apps (click, type, read text, etc.).
  • Web automation (browser‑based UIs) via browser extensions.
  • File system operations, PowerShell, command line, etc.
• Trigger model:
  • Native triggers inside Power Automate for desktop (e.g. run when a specific file is created in a folder, or manually run from the desktop app).
  • Or triggered remotely by a cloud flow using the Run a desktop flow action.
• Dependencies:
  • Requires the desktop runtime installed and configured.
  • For unattended runs, requires an appropriate licence and machine registration in Power Automate.

In the scenario:

• The desktop flow is the right tool for:
  • Opening the legacy Windows client.
  • Logging in (if credentials can be handled securely).
  • Navigating forms and entering the approved order data.

Desktop flows do not run in the cloud; if the target machine is off, locked, or misconfigured, the run will fail or wait, depending on configuration.

Cloud Flow vs Desktop Flow: Core Differences That Actually Matter

For practitioners, the key differences boil down to where the work happens, how reliable the run is, and what you can automate.

1. Execution Environment

• Cloud flow:
  • Runs entirely in the Power Automate cloud.
  • No dependency on a specific PC being on, except when it invokes a desktop flow.
• Desktop flow:
  • Runs on a specific Windows machine.
  • Depends on:
    • Machine availability.
    • Runtime service health.
    • Correct user session state (especially for attended runs).

Decision impact in the scenario:

• The approval and API calls should be cloud‑only for reliability.
• The legacy client automation must be desktop‑based, but you choose where that desktop flow runs (e.g. a dedicated unattended VM).

2. Trigger and Scheduling Options

• Cloud flows:
  • Rich trigger set via connectors.
  • Native recurrence/scheduling in the cloud.
  • Can be invoked by Power Apps, HTTP requests, webhooks, etc.
• Desktop flows:
  • Native triggers are local (e.g. file events, manual run).
  • For enterprise orchestration, they’re usually triggered by a cloud flow, not on a schedule inside the desktop app.

In practice:

• If the business event lives in a SaaS system (SharePoint, Dynamics 365, custom API), start with a cloud flow.
• Use the cloud flow to fan out to desktop flows when you hit UI‑only or legacy systems.

3. Connectivity and Data Access

• Cloud flow:
  • Ideal for systems with APIs or connectors.
  • Can reach on‑premises databases and file shares via gateway.
  • Handles authentication through connection references and service principals (depending on connector and environment setup).
• Desktop flow:
  • Ideal for systems that don’t have APIs but have a stable UI.
  • Can still call APIs via HTTP actions or PowerShell, but that’s secondary; its main strength is UI automation.

In the scenario:

• SaaS ERP with a documented API → cloud flow.
• Legacy Windows client with no supported API → desktop flow.

4. Error Handling and Observability

• Cloud flow:
  • Run history and per‑action status in the Power Automate portal.
  • Configurable retries on many actions.
  • Can send notifications, write logs to Dataverse, Application Insights, etc.
• Desktop flow:
  • Run history visible in Power Automate portal as well when triggered from cloud.
  • UI automation is inherently more fragile (layout changes, timing issues).
  • Requires more defensive scripting (waits, checks, error branches).

This matters when you’re deciding where to put logic:

• Business logic with clear APIs → cloud flow for more predictable runs.
• UI‑driven logic → desktop flow, but expect more maintenance.

5. Licensing and Capacity (High‑Level Only)

Licensing details change often and depend on tenant configuration, so only the stable patterns:

• Cloud flows:
  • Included in several Microsoft 365 and Dynamics licences.
  • Also available via standalone Power Automate licences.
• Desktop flows:
  • Attended RPA (user present) and unattended RPA (no user) have different licence requirements.
  • Unattended runs typically require additional RPA‑specific licences and machine registration.

For the scenario:

• If you need unattended desktop runs on a VM, you must check current RPA licence requirements with your admin. Cloud‑only flows may already be covered by existing Microsoft 365 licences.

Designing the Combined Solution: One Scenario End‑to‑End

Let’s design the monthly order processing solution in a way that uses both flow types correctly.

Step 1: Cloud Flow for Event, Approval, and API

Build an automated cloud flow with a SharePoint trigger:

• Trigger: When an item is created in the Orders list.
• Actions:
  1. Get item details.
  2. Start an approval in Teams.
  3. Wait for approval outcome.
  4. If approved:
     • Call SaaS ERP API via HTTP or connector.
     • Trigger the desktop flow for the legacy client.

The trigger for the desktop flow is the Run a desktop flow action:

• You select the desktop flow.
• You pass parameters (e.g. OrderId, CustomerName, Amount) into the desktop flow.

At this point, the cloud flow is orchestrating; it doesn’t care which machine runs the desktop flow, as long as the machine is registered and available.

Step 2: Desktop Flow for Legacy Client UI Automation

In Power Automate for desktop, you build a desktop flow that:

1. Receives input parameters from the cloud flow.
2. Opens the legacy client (if not already open).
3. Logs in (if required and allowed by your security policy).
4. Navigates to the order entry screen.
5. Types in the fields.
6. Saves and closes or leaves the app in a stable state.

Example of a simple login + data entry sequence (described, not full UI script, because the actual actions depend on the specific app):

• Use “Launch application” action to start the client.
• Use “Wait for window” to ensure the login window is ready.
• Use “Populate text field on window” actions for username/password.
• Use “Press button on window” to submit.
• Use a combination of “Click UI element in window” and “Populate text field on window” to fill in order fields.

You then expose input variables in the desktop flow so the cloud flow can pass data in.

Step 3: Handling Failures and Retries

With both flows in place, decide where to put resilience:

• In the cloud flow:
  • Use built‑in retry policies for API calls where appropriate.
  • Branch on approval outcome and API call success/failure.
  • Log failures to a central location (e.g. Dataverse table or SharePoint list).
• In the desktop flow:
  • Use explicit waits (wait for window, wait for text, etc.).
  • Add conditional branches if a window or element is not found.
  • Return a clear success/failure result to the cloud flow.

The cloud flow can then decide:

• If the desktop flow fails, mark the order as “Legacy entry failed” and notify operations.
• Optionally queue a retry by re‑running the desktop flow later, depending on business rules.

When You Only Need One Type

Not every process needs both.

Choose Cloud Flows Only When:

• All systems involved expose APIs or connectors.
• The process can be fully expressed as data movement and service calls.
• You want:
  • High reliability independent of user PCs.
  • Easier scaling and monitoring.

Example:

• New order in Dataverse → approval in Teams → write to SQL via gateway → send email confirmation.

No desktop flow needed.

Choose Desktop Flows Only When:

• The process is entirely local to a machine and not driven by SaaS events.
• Example: A finance desktop tool that you open once a week to export a report, then transform it locally.

Even here, many teams still wrap a cloud flow around desktop flows to get central logging and orchestration, but technically you can run only desktop flows.

Common Beginner Missteps (And How to Avoid Them)

Misstep 1: Expecting a Desktop Flow to Run “In the Cloud”

Beginners often assume a desktop flow will run even if their PC is off because they see it in the Power Automate portal.

Reality:

• The desktop flow runs on the machine where Power Automate for desktop is installed and configured.
• For unattended runs, that machine must be online and properly registered.

Avoid it:

• For anything critical, run desktop flows on dedicated, managed machines, not personal laptops.

Misstep 2: Trying to Use Desktop Flows for Pure API Work

Some teams build desktop flows to drive web UIs that already have stable APIs.

Issues:

• More fragile (UI changes, timing issues).
• Harder to maintain than API‑based cloud flows.

Avoid it:

• If a system has a supported connector or API, use a cloud flow.
• Reserve desktop flows for genuinely UI‑only or legacy cases.

Misstep 3: Mixing Business Logic Into Desktop Flows

Putting business rules (e.g. approval logic, branching by customer type) into desktop flows makes them harder to reuse and test.

Avoid it:

• Keep business logic and orchestration in cloud flows.
• Keep desktop flows focused on UI execution.

Practical Takeaway: Start in the Cloud, Add Desktop Only Where Needed

For any new automation, sketch the data flow first:

• If the trigger, approvals, and data movement live in SaaS or API‑accessible systems, design a cloud flow first.
• Only introduce a desktop flow where you hit a hard UI boundary with no reliable API.

That single decision—cloud first, desktop where necessary—will keep your architecture understandable, your runs more reliable, and your RPA footprint limited to the places it actually adds value.