Loading tutorials…
Loading tutorials…
Cloud flows work for apps with APIs. Desktop flows (RPA) work for legacy apps without APIs — your bank portal, your CRM from 2008, the spreadsheet someone copies from one system to another every morning. This walks the right setup.
Who this is forOperators or IT teams automating legacy or desktop-only software. If your business has a process that involves a human clicking through a UI to move data between systems, RPA can replace it — but only when set up correctly.
What you'll need
Step 1
Desktop flows require Per-User with attended RPA ($40/user/mo) for attended RPA, or per-bot pricing for unattended. Free trial available for testing.
Desktop flows (RPA) are NOT included in Standard Power Automate.
Attended RPA (bot runs on a human-supervised machine): Per User with attended RPA at ~$40/user/mo.
Unattended RPA (bot runs on a dedicated machine, fully autonomous): per-bot pricing at ~$150/bot/mo, requires production machine + license.
For evaluation: Microsoft offers a 90-day free trial of attended RPA. Use this for the first 1-2 flows to validate fit.
Critical: budget for licensing BEFORE designing flows. RPA economics only work when the human time saved exceeds the license cost.
Step 2
Download from Microsoft. Install on the target Windows machine. Sign in with the licensed M365 account.
Go to powerautomate.microsoft.com → Download Power Automate for Desktop.
Run the installer on the Windows machine where flows will execute. Admin rights required.
After install, launch Power Automate for Desktop. Sign in with the M365 work account that has the Per-User with attended RPA license.
The first launch downloads additional components and may take 5-10 minutes.
Open the cloud portal (make.powerautomate.com) → My Flows → Desktop Flows. Your machine should appear under "Machines."
Step 3
In the Desktop app, click "+ New" → use the Recorder. Click through the target app once. Power Automate captures actions.
In Power Automate for Desktop, click "+ New."
Name the flow descriptively.
Click "Recorder" in the top toolbar. The recorder opens as a small floating panel.
In the target app (legacy CRM, web portal, spreadsheet), perform the workflow manually once: click buttons, fill fields, etc.
Each action is captured as a step in the flow. You can pause/resume the recorder.
Stop recording. Review the captured steps — rename fields, add comments, verify selectors.
CRITICAL: Test the recorded flow once before refining. Many recorded flows need manual adjustment to selectors.
Step 4
Recorded flows are brittle. Add variables for changing data. Tune selectors to use stable element IDs, not positional clicks.
Recorded flows use whatever data you typed during recording. Replace hardcoded values with variables for inputs that change per run.
Click any "Set text" or "Click on UI element" action → replace hardcoded text with a variable (e.g., `%CustomerEmail%`).
For UI element selectors: prefer selectors that use stable attributes (element ID, accessibility name) over positional/visual selectors.
If the target app changes layouts, positional selectors break immediately. Stable selectors survive minor UI updates.
Power Automate Desktop shows selector type in the action; pick "Use selector by attribute" when available.
Step 5
Wrap critical sections in try/catch blocks. Add error handlers that log + notify on failure rather than silent halt.
Power Automate Desktop has built-in error handling.
Right-click any action → "Block error handling" or wrap a section with "On block error" / "Catch block."
For each error: log to a file, send a Teams message via cloud-flow trigger, or capture a screenshot of the failed state.
Critical pattern: do NOT let RPA flows halt silently. Every failure should be logged with: timestamp, flow name, failed step, error details, screenshot if possible.
Without error handling, RPA flows fail and you discover days later that data has not been moving.
Step 6
Trigger desktop flows from cloud flows. Use Schedule trigger + "Run a flow built with Power Automate Desktop" action.
Open Power Automate cloud portal → Create → Scheduled cloud flow.
Set the schedule (every weekday at 6 AM, every 30 minutes during business hours, etc.).
Add action: "Run a flow built with Power Automate Desktop." Pick your desktop flow and the machine to run it on.
For unattended runs: the machine must be powered on, logged in, and the Desktop app running.
Cloud flow scheduling + desktop flow execution = the standard production pattern.
Step 7
Build a monitoring cloud flow that checks RPA run history daily and alerts on failures or missed schedules.
Create a separate cloud flow: "RPA Health Monitor."
Schedule daily at 7 AM.
Use the Power Automate Management connector (Premium) to query flow run history for your RPA flows.
If any flow had a failure or missed run in the last 24 hours, post to a Teams channel: "RPA flow [name] failed [N] times yesterday."
This catches the worst RPA failure mode: bot halted silently and nobody knows. Daily monitoring is mandatory.
Common mistakes
Building RPA flows without budgeting for licensing
What goes wrong: You build 3 RPA flows during the 90-day trial. On day 91, they all stop. You scramble for budget approval — Per-User with attended RPA is ~$40/user/mo per machine. For 3 machines that is $1,440/year unbudgeted.
How to avoid: Get licensing approval BEFORE building production RPA flows. Run the math: human hours saved × hourly rate > license cost = RPA is worth it.
Using positional/image selectors that break on UI changes
What goes wrong: Recorded flow uses 'click 245 pixels from top, 180 from left.' Target app gets a minor UI update next week — adds a banner. Every coordinate shifts 60px down. The flow clicks wrong elements, corrupts data, or fails.
How to avoid: After recording, replace every positional/image selector with an attribute-based selector (element ID, accessibility name, XPath). Resilience tax of 30-60 min per flow saves weeks of break-fix.
No error handling — silent failures
What goes wrong: RPA flow fails on a edge case once a week. No error handler. No log. No alert. You discover 6 weeks later that 30 records have not been processed. Some are time-sensitive. Customer-facing breakage.
How to avoid: Wrap critical sections in try/catch. Log every failure with timestamp, step, error details. Pipe failures to a monitored Teams channel.
Single-machine production with no failover
What goes wrong: Production RPA flows run on one machine. That machine crashes, Windows updates restart it, or someone unplugs it. All RPA halts. Hours to days of business processes stop.
How to avoid: For business-critical RPA: provision two production machines. Configure flows to fall over to the secondary if primary fails. Add monitoring that pages on machine offline.
Bots that need human attention but run "unattended"
What goes wrong: Flow runs unattended overnight. Encounters a CAPTCHA or unexpected pop-up. No human to dismiss. Bot stuck for 8 hours doing nothing. Business processes back up.
How to avoid: Design unattended flows defensively: timeout every action, handle unexpected pop-ups, escalate stuck states to a human via Teams alert. Or run attended on a human-supervised machine.
No daily monitoring digest
What goes wrong: RPA flow stops firing on its schedule because the target app added new login requirements. The scheduled trigger fires but the flow halts on the first new screen. Nobody notices for 2 weeks.
How to avoid: Build a daily monitoring cloud flow that checks every RPA run history. Alert on failures, missed runs, or longer-than-usual durations.
Recap
Done — what's next
How to set up Power Automate cloud flows
Read the next tutorial
Hand it off
RPA flows are powerful when stable and fragile by default. EverestX specialists with RPA experience design for resilience: stable selectors, error handling, monitoring, machine redundancy. Most teams that DIY RPA spend more on break-fix labor than they save in human time — until they bring in expertise.
See specialist rates
Cloud flows connect cloud apps via APIs (SharePoint, Teams, third-party SaaS). Desktop flows automate desktop UIs (legacy apps, web portals, spreadsheets) by simulating clicks. Both can be combined.
Microsoft offers a 90-day free trial of Per-User with attended RPA. After the trial, production use requires licensing. Some basic recording functionality works without a license but cannot be scheduled or run unattended.
Properly built (attribute-based selectors, error handling, monitoring) — they can run for months without intervention. Recorded-and-shipped — typically break weekly. The resilience tax of 30-60 min per flow saves dozens of hours of maintenance.
Not by themselves. For sites with CAPTCHAs, either: (1) attended RPA where a human solves them, (2) third-party CAPTCHA-solving services (paid, ethical considerations), or (3) negotiate API access with the vendor.
Attended: bot runs on a human-supervised machine, often in a corner of the screen. The human can interrupt or assist. Unattended: bot runs on a dedicated server-style machine 24/7 with no human interaction. Unattended requires more licensing and more resilience engineering.
Microsoft Power Automate
Power Automate is the right call when your stack lives in Microsoft 365 — but the licensing maze and Premium connector trap catch most newcomers. This walks the right setup path end-to-end, in plain language.
Microsoft Power Automate
Power Automate disables flows after 14 days of consecutive failures (default). By the time you notice, weeks of automation are gone. This walks the error-handling pattern that catches problems early.
Microsoft Power Automate
Your flow worked yesterday. Today it returns 429 'Too Many Requests.' Power Automate connector limits are real and per-license-tier. This walks the diagnostic sequence specialists run.
Microsoft Power Automate
DIY Power Automate is great until you have 15 flows, Premium licensing confusion, and a SharePoint admin asking why their list keeps getting cluttered. This is the honest framework: when the cost of self-managing exceeds the cost of hiring.
Zapier
One trigger, three or four actions. Easy to draw on a whiteboard, easy to break in production. This walks through chaining, naming, and the error scenarios that hit you on day 30, not day 1.