Power Automate Desktop Patterns

Fundamentals

Power Automate Desktop (PAD) is the robotic process automation engine in Power Automate — it drives Windows desktop apps, browsers, files, and legacy systems the way a person would. You build desktop flows in the flow designer by sequencing actions; the console lists your flows and launches runs. Every flow has a Main subflow that runs first, and you call other subflows with Run subflow.

• Actions are the building blocks — each is a configured step (launch Excel, click a button, set a variable). Rename them; the name becomes how you reference outputs.
• Subflows group actions for reuse and readability. Main always exists and always runs first; add more from the subflow tabs.
• Variable scope. Global subflows expose variables across the whole flow; local subflows keep variables private — reference a global from a local subflow with the global. prefix.
• Machines & connections. A desktop flow runs on a registered machine (or machine group); a desktop flow connection lets cloud flows sign in and trigger it. Gateways are retired — use direct connectivity.
• Attended vs unattended. Attended runs share your signed-in session; unattended runs spin up their own locked Windows session (no users signed in) and need the Power Automate Process plan.

Variables & the % notation

Every variable reference is wrapped in percentage signs: %VariableName%. Anything between % is *evaluated* — a variable, a property, or a whole expression. To print a literal percent character, escape it by doubling: %%.

• Hard-coded text goes in quotes inside an expression: %'this is ' + 'text'% → this is text.
• Property access uses dot notation inside the percents: %Files.Count%, %CurrentItem.FullName%, %varDate.Year%.
• Blank / null. Any variable can hold a Blank value; test it with the Is blank / Is not blank options on conditional actions.
• Names matter. A variable name can’t be a reserved keyword (see the table at the end) — that includes everyday words like action, step, error, and next.

Data types

PAD infers a variable’s type from its content. Simple types hold one value; advanced types are collections; instances are live handles to an app or connection that you pass between actions.

Lists, datatables & custom objects

Build a datatable inline

%{ ^['Product', 'Price'], ['Product1', '10 USD'], ['Product2', '20 USD'] }%

Datatype properties

Many types carry read-only properties you access with %Variable.Property% — no extra action required.

Conditionals

Use If / Else if / Else to branch on any condition, and Switch / Case / Default case to match one value against many. Conditions can be a simple operand-operator-operand comparison or a full %…% logical expression.

One If with a logical expression beats nested Ifs

First operand:  %A = 10 AND B = 5%
Operator:       Equal to (=)
Second operand: %True%

Loops

For each over a list (designer copy-paste)

LOOP FOREACH CurrentItem IN $fx'=varFiles'
    # ... actions using CurrentItem ...
END

Flow control & organisation

Error handling

By default a desktop flow stops on the first error. Assume every UI click, file op, and web call can fail, and decide per action — or per block — what should happen instead.

• Per-action On error. Open an action’s On error tab to set a Retry (N times, every M seconds), then Continue flow run (*Go to next action*, *Repeat action*, or *Go to label*), plus rules to Set variable or Run subflow. Use Advanced to handle different errors differently.
• On block error. Wrap a group of actions in a Block to apply one error policy to all of them — including a Retry policy (None / Fixed / Exponential) and Handle flow terminating errors to also catch logic errors like out-of-bounds indexing or divide-by-zero.
• Get last error. Retrieves the most recent error into an error variable; enable Clear error so you don’t re-read it later.
• Throw custom error. Raises your own named error — place it inside an On block error and add a matching + Custom error entry to handle it.
• Self-healing (preview). For single-element UI/browser actions that hit *Element not found*, an AI fallback can re-find the element at runtime, in the order: Retry → Self-healing → Set variable / Run subflow → Continue / Throw.

FlowLibs Try/Catch pattern (copy-paste)

SomeAction Parameter: $fx'value' Output=> Result
    ON ERROR REPEAT 1 TIMES WAIT 2
    ON ERROR
        CALL Subflow_ErrorLogging
        THROW ERROR
    END

Block-level handler

BLOCK 'Create HTML Table'
ON BLOCK ERROR REPEAT 1 TIMES WAIT 2
ON BLOCK ERROR
    CALL Subflow_ErrorLogging
    THROW ERROR
END
    # ... all actions inside the block ...
END

UI automation & selectors

UI automation drives Windows desktop apps. Each target is a UI element described by one or more selectors — a hierarchy that uses the > notation, where each level is contained in the one to its left. Window-level selectors start from the :desktop root.

:desktop > window[Name="%WindowName%"][Process="Notepad"] > menu "Application" > menu item "File"

• Add multiple selectors to one element — PAD tries them in order, so a fallback survives minor UI changes.
• Make selectors static. Replace Equals to with Starts with / Ends with / Contains or a regex to strip dynamic bits (e.g. a trailing (2) or a counter in a window title).
• Test selector and Repair selector from the selector builder before blaming the flow — and recapture on the actual unattended machine, where resolution and DPI differ.
• Run as administrator when automating an elevated app — PAD must run at the same or higher privilege than its target.

Browser & web automation

Browser automation targets web pages. Launch a browser instance (Chrome, Edge, Firefox, or the automation browser), then act on web UI elements captured with HTML attribute selectors. Web actions need a *browser* instance — desktop UI actions won’t see web elements and vice-versa.

Excel automation

Excel actions work against an Excel instance from Launch Excel (or Attach to running Excel). Read a range into a datatable, manipulate it in memory, and write it back — far faster than clicking cells through UI automation.

Excel.ReadFromExcel.ReadAllCells Instance: $fx'=ExcelInstance' GetCellContentsMode: Excel.GetCellContentsMode.TypedValues FirstLineIsHeader: True RangeValue=> ExcelData

Files, folders & text

Scripting & Power Fx

When no action fits, drop to a script; and on newer flows you can author logic in Power Fx instead of the classic %…% expressions.

Cloud orchestration

Desktop flows usually run as a step inside a cloud flow. Add Run a flow built with Power Automate for desktop, pick the connection and run mode, and pass data through input/output variables.

• Input variables flow cloud → desktop; output variables flow desktop → cloud. Mark sensitive inputs as sensitive so they’re obfuscated in logs.
• Run modes. *Attended* runs in your signed-in session; *unattended* creates a locked RDP session (all users must be signed out) and needs the Process license. *Picture-in-picture* is attended-only.
• Trigger options. Cloud flow step, the console, a desktop shortcut, or a run URL (browser / Run dialog / Task Scheduler).

PAD copy-paste designer syntax

PAD actions are plain text you can copy straight into the designer — paste them and they become real actions. Getting the string enclosure right is everything: one wrong quote style and the paste fails silently. There are exactly three.

• Backslashes double inside `$'''…'''` — C:\\Users\\.... This rule does not apply inside $fx'…'.
• `%var%` for literal strings, `${var}` for fx strings. %var% substitutes inside triple-quotes; ${var} interpolates inside $fx'…'.
• Datatable columns: dot notation inside `$fx`, brackets only when bare. $fx'${Row.Name}' is valid; $fx'${Row[''Name'']}' is not — use Row['Name'] as a bare reference or in an IF condition.
• `=>` marks every output (no spaces in the parameter name): Instance=> ExcelInstance, Response=> RawReturn.
• `REGION / ENDREGION` group actions (double asterisks); name variables varCamelCase.

The three enclosures side by side

SET varDownloads TO $'''C:\\Users\\%varUser%\\Downloads'''
SET varMessage   TO $fx'Found ${varFileCount} files to clean.'
SET varFileCount TO $fx'= CountRows( varFiles )'
SET varErrorMsg  TO LastError.Message

Reusable patterns

Composite, ready-to-copy building blocks. Adapt the variable names; keep the structure.

Logging call

**REGION Logging
SET varCurrentMessage TO $fx'Your message here'
CALL Subflow_Logging
**ENDREGION

Early exit when there is nothing to do

SET varFileCount TO $fx'= CountRows( varFiles )'
IF varFileCount = 0 THEN
    **REGION Logging
    SET varCurrentMessage TO $fx'No records found to process'
    CALL Subflow_Logging
    **ENDREGION
    EXIT Code: $fx'=0'
ELSE
    **REGION Logging
    SET varCurrentMessage TO $fx'Found ${varFileCount} records to process.'
    CALL Subflow_Logging
    **ENDREGION
END

Process loop with counter + per-item logging

SET varProcessedCount TO $fx'0'
LOOP FOREACH CurrentItem IN $fx'=varFiles'
    Variables.IncreaseVariable Value: $fx'=varProcessedCount' IncrementValue: $fx'1'
    **REGION Logging
    SET varCurrentMessage TO $fx'Processing item ${CurrentItem.FullName}'
    CALL Subflow_Logging
    **ENDREGION
    # ... processing logic ...
END
**REGION Logging
SET varCurrentMessage TO $fx'Processed ${varProcessedCount} items'
CALL Subflow_Logging
**ENDREGION

Action guarded by retry + error logging

Folder.GetFiles Folder: $fx'${varPickupFolder}' FileFilter: $fx'*.csv' IncludeSubfolders: False FailOnAccessDenied: True Files=> varFiles
    ON ERROR REPEAT 1 TIMES WAIT 2
    ON ERROR
        CALL Subflow_ErrorLogging
        THROW ERROR
    END

Best practices & ALM

• Rename actions and use Regions. Get_open_orders beats Get_files_3. Names become references; regions make a long Main readable.
• Extract reuse into subflows. A logging subflow, an error-logging subflow, and a set-variables subflow keep Main short and consistent.
• Robust selectors. Multiple selectors + static attributes + a retry policy; recapture on the unattended machine.
• Error handling everywhere it can fail. File, web, UI, and cloud-connector actions get an ON ERROR (retry → log → throw) or sit inside an On block error.
• No secrets inline. Use sensitive inputs, environment variables, or Key Vault — never hard-code credentials, and never log them.
• Solution-aware + versioned. Author in a solution, bump the version each release, and promote DEV → TEST → PROD; keep the Default environment locked down.
• Test on the target machine. Resolution, DPI, app versions, and permissions differ unattended — validate there, not just in the designer.

Reserved keywords

These words are reserved by the PAD engine and can’t be used for variable names, custom-object properties, or custom action names/properties. They’re case-insensitive (ACTION = action).