Desktop flow triggers and scheduling

What it does

Covers every way a desktop flow gets started: the Run a flow built with Power Automate for desktop action in a cloud flow, run URLs and desktop shortcuts on the local machine, the in-flow trigger action that waits for a UI event, and the new direct scheduling experience. Whichever route you take, the run lands in a queue against a machine or machine group and waits its turn.

Key facts

The cloud flow route needs a registered machine or machine group, a work or school account, and a desktop flow connection. Any cloud flow trigger — event, schedule, button — becomes a desktop flow trigger by extension.
Input and output variables carry data between the cloud flow and the desktop flow. Desktop flow input is capped at 2 MB (1 MB in China regions).
Up to 70 desktop flow runs per minute per connection is the documented throughput ceiling.
Cancelling the parent cloud flow doesn't stop child desktop flows if the Asynchronous Pattern setting is switched off on the action.
Run priority is a High/Normal parameter under advanced options on the connector action, and it can be passed dynamically. Ordering is by priority then enqueued time. Owners and machine admins can change a queued run's priority or move it to the top.
Queue statuses are Running, Queued and Next to run. Maximum queued time is 12 hours.
Extended queue prioritisation applies on multi-session machines such as Windows Server with RDS. It lets the assignment algorithm skip past a run that can't be placed rather than blocking the queue behind it. It turns itself on when multi-session support is detected, and you can opt out.
Locally, flows can be started by run URL (ms-powerautomate:/console/flow/run?...), a desktop shortcut, the command prompt, or Windows Task Scheduler, with optional inputArguments, autologin and runId parameters. Only one flow runs in local attended mode at a time, and this route needs a Power Automate Premium plan or a pay-as-you-go environment.
Inside a flow, the trigger action sets up mouse-click or keyboard-event triggers on UI elements and pauses the run until one fires, in one-time or sequential mode with an optional timeout.
Schedule desktop flows directly entered public preview in July 2026 (2026 wave 1). It attaches schedules to desktop flows in Automation Center without a cloud flow, binding directly to the machine or machine group, with a unified Schedules list. Preview — don't build production scheduling on it yet.

When to use / skip

The cloud flow route is the default and stays the default until direct scheduling reaches general availability, because it gives you connectors, conditions, error handling and proper run history around the desktop flow. Local run URLs and Task Scheduler are for genuinely machine-local, attended scenarios — a user's own shortcut, or a legacy on-box schedule the client won't give up. Avoid Task Scheduler as a production orchestration layer; you lose central monitoring, queue management and priority, which are the things that make the platform worth paying for.

Configuration decisions

Where the schedule lives: a cloud flow recurrence, Windows Task Scheduler, or the new direct schedules once they're generally available.
Run priority per process, and who is allowed to override it in the queue.
Whether the asynchronous pattern is on, which decides if cancelling the parent actually stops the work.
Whether the confirmation dialog for URL and shortcut invocation stays enabled — turning it off is convenient and is a documented security risk.
How queue depth and the 12-hour queued limit shape your scheduling windows.

Gotchas

Scheduling everything for 9am is the classic mistake. The queue is best-effort FIFO and everything piles into the same machines; stagger the schedules.
A run URL does nothing if the flow is already running. There's no error to speak of, it just doesn't start again.
Hidden schedules buried inside cloud flows are the reason direct scheduling exists. Until it ships properly, keep a register of what is scheduled where.
Task Scheduler invocation differs between MSI and Microsoft Store installs — different executable, different argument syntax. Copying a working command between machines fails if the install type differs.
Runs queued longer than 12 hours are lost, which turns an overnight backlog into missing work rather than late work.

Consultant notes

Insist on a single orchestration pattern per client. Mixed cloud flow schedules, Task Scheduler entries and desktop shortcuts make incident triage genuinely difficult.
Priority is worth designing deliberately: name the two or three processes that outrank everything else and set them High. If everything is High, nothing is.
Direct scheduling is a good thing to mention in roadmap conversations, clearly flagged as preview as of July 2026, without building the design around it.
Show operations the run queue view early. Being able to see and reorder queued work is what turns RPA from a black box into something they'll accept ownership of.

Recheck once direct desktop flow schedules reach general availability — the recommended pattern will change