Power Automate Desktop Production Reliability: Best Practices for Enterprise RPA
A technical guide to building unattended desktop flows that survive contact with a real production environment, and to fixing the ones that have not.
Is Power Automate Desktop reliable for production RPA? Yes, with proper design. This guide shares our proven practices for resilient unattended flows: robust selectors, error handling, checkpoint logic, and monitoring, based on real enterprise automation builds we deliver from our Yerevan center. The failures that take desktop flows down in production are predictable ones. A recorded selector that breaks the next time the target application updates. A fixed wait that is one second too short on a slow morning. An unattended run that cannot take a session because somebody stayed signed in. A flow that has no idea which records it already processed when it restarts.
The six ways desktop flows actually fail in production
Almost every unreliable automation we are asked to look at is one of these six, and each one has a single practice that prevents it. Start from the symptom you are seeing rather than from the top of a checklist.
| What you see | What is really happening | The practice that prevents it |
|---|---|---|
| It worked all week in the designer and failed the first night it ran unattended | An attended run borrows your signed in session: your screen resolution, your desktop, your browser profile, your already open applications. An unattended run gets a fresh session with none of that. | Build against an unattended run on the target machine from the first day, not as the last step before go live. |
| It ran fine for months and then broke overnight with nothing changed on our side | The target application or the browser updated and moved, renamed, or reordered the element the recorded selector depended on. Recorded selectors carry the whole element hierarchy and volatile attributes such as position and generated identifiers. | Rewrite the recorder output by hand against stable attributes, and control the update channel of the applications and browsers you automate. |
| The run reports success but the data is duplicated or partly missing | The flow restarted, or an item was retried, and the side effects ran twice. A loop over a spreadsheet with no per item status cannot tell the difference between a fresh run and a resumed one. | Drive the work from a queue with a status per item and an idempotency key, so a retry can be safely replayed. |
| The run hangs and holds the machine until somebody notices | The flow is waiting on a UI element that will never appear, usually because an unexpected dialog, a session expiry prompt, or an error page interrupted the path. | Every wait gets a timeout, every block gets error handling, and a failure captures a screenshot before the flow exits cleanly. |
| Runs queue up behind each other and miss the processing window | One machine, one session, long monolithic flows. Unattended capacity is per machine session, so a single long run blocks everything behind it. | Split the process into smaller desktop flows orchestrated by a cloud flow, and run them across a machine group rather than one machine. |
| Nobody noticed the automation had been failing for a week | The only place the failure was visible was the run history, and nobody opens the run history when things look calm. | Alert on failure from a cloud flow, and add a business level reconciliation check that proves the work was actually done. |
Microsoft's own documentation covers the mechanics of every one of these controls, from selector syntax to error handling to machine groups. What it does not do, because it cannot, is tell you which of them your specific process needs and in what order. That is the part below.
Ten practices for resilient unattended desktop flows
Do not automate the user interface if there is any other way in
Desktop flows are the right answer when a system has no API, no database access, and no connector. They are the wrong answer when one exists and nobody looked. A cloud flow calling a REST endpoint, a custom connector built from an OpenAPI definition, a SQL query, or an Office Script will outlive every selector you write. The most reliable UI automation in a process is the part you managed to remove. We start every Power Automate engagement by drawing the line between what genuinely needs the screen and what does not, because everything after this decision is more expensive to keep running.
Ship hand written selectors, not the recorder output
The recorder gives you a working selector and a maintenance problem. It captures the full ancestor chain and whatever attributes happened to be there, including ordinal position and generated identifiers that change on the next render. Open the UI elements repository and rebuild each one in the custom selector editor: keep the attributes that describe what the element is, such as an automation identifier, a control name, or a stable class, and drop the ones that describe where it happened to be. Use the operators the editor gives you, contains and starts with and regular expressions, so a selector survives a caption that includes a document name, a record count, or a date.
Wait for a condition, never for the clock
A fixed delay is a guess about somebody else's server on a good day. It is too long on every normal run and too short on the one morning the system is busy, which is exactly the morning the flow needs to work. Use the waiting actions that check for the thing you actually need: wait for a window, wait for the element to contain text, wait for the web page content to load, wait for a file to exist. Give each one a timeout, and make the timeout path a real error with a message that says what was being waited for, rather than a silent fall through into the next action.
Design every block for the failure, not the happy path
Power Automate Desktop lets you set error handling per action and per block: how many times to retry, how long to wait between attempts, whether to continue or throw, and which subflow to run when things go wrong. Use it deliberately. Transient failures such as a slow load or a locked file deserve a couple of retries. A missing record does not, and should stop the item with a clear reason. Every flow gets a cleanup subflow that closes applications, releases the file handles, and leaves the session in a known state, because the next run starts on the same machine and inherits whatever the last one left behind.
Make the flow restartable
Assume the run will be interrupted, because eventually it will be: a machine reboot, a patch window, a lost connection. A restartable flow reads its work from a queue rather than iterating over a list in memory, marks each item as it moves through the stages, and can be started again without asking anybody what it already did. Power Automate work queues in Dataverse give you this with retry and item state built in, and a plain Dataverse table works too when the process is simple. Add an idempotency key on the target side so a replayed item updates the same record instead of creating a second one.
Treat the unattended session as a different environment
An unattended run signs in and creates its own session, and that session is not your desktop. The screen resolution is whatever the machine settings say, not what your monitor does, and any action that depends on where something is on screen or on how an image looks will behave differently. There is no console user, so anything that assumed an already open application or a warm browser profile fails. If a person is signed in at that machine, the unattended run cannot take the session at all. Fix the resolution and scaling in the machine settings, keep the account locale and regional format identical to what the flow expects, and prefer selector based actions over image and coordinate based ones everywhere you can.
Keep secrets out of the flow definition
Credentials typed into an action live in the flow definition, travel with every export, and show up in logs and screenshots. Hold them in Azure Key Vault, retrieve them in the calling cloud flow, and pass them into the desktop flow as input variables marked sensitive so they are masked in the run history. Where an enterprise vault is already in place, use it rather than creating a second one. The same rule applies to the account the machine group signs in with: a dedicated service account with only the access the process needs, managed by whoever owns identity, and rotated on their schedule rather than yours.
Keep the machine group in a known state
A desktop flow is only as stable as the Windows image under it. Use dedicated machines that nobody works on interactively, group them so runs can queue and fail over instead of piling onto one host, and treat every change to the image as a change to the automation. That means a controlled update schedule for Windows, for the applications being automated, and for the browsers, because a browser that updates itself overnight will break web automation before anybody is awake. Make sure the browser extension the flow needs is installed and enabled on every machine in the group, keep the runtime version consistent across the group, and stop the machines from sleeping or locking in a way that interferes with a run.
Instrument the run so a failure finds you
Desktop flow runs are recorded in Dataverse, which means the run history is queryable data and not just a screen. Build a cloud flow that reacts to a failed run and posts to a Teams channel or raises a ticket with the flow name, the machine, the item that failed, and the error. Capture a screenshot in the error path, because a picture of the unexpected dialog saves an afternoon of guessing. Then add the check that actually matters to the business: a reconciliation that compares what should have been processed against what was, so a run that completed successfully while doing nothing useful still raises a flag.
Change it through solutions, never in production
Desktop flows are solution aware, so they get the same application lifecycle discipline as the rest of the Power Platform. Build in a development environment, hold anything environment specific in environment variables and connection references rather than in the flow, export a managed solution, and promote it through test to production. Keep the solution in source control and let a pipeline do the deployment. The alternative, editing the live flow because the fix is small, is how a process that works becomes a process nobody can rebuild, and it is the single most common thing we find when we are asked to take over an automation estate that has stopped being trustworthy.
Step-by-step: hardening a desktop flow for unattended production
This is the order we work in, whether we are building a new automation or rescuing one that has stopped being trusted. Steps 1 to 3 change the shape of the process, steps 4 to 8 harden the flow and the machines it runs on, and steps 9 and 10 prove it works and get it into production properly.
Confirm that UI automation is the right tool for each step
Walk the process step by step and ask, for each one, whether the system involved exposes an API, a connector, a database, or a file drop. Move everything that does out of the desktop flow and into a cloud flow or a custom connector. What is left is the genuine RPA surface, and it should be as small as you can make it. This is the cheapest reliability work available, because a step that no longer touches a screen cannot be broken by a screen change.
Break the process into units that can each be retried on their own
Define the unit of work, usually one invoice, one order, one customer record, and make sure each unit can succeed or fail without affecting the others. Split a long monolithic flow into subflows and, where the stages are genuinely separate, into separate desktop flows orchestrated by a cloud flow. Small units retry cheaply, run in parallel across a machine group, and give you a failure you can describe in one sentence instead of a run that died somewhere in the middle of an hour.
Drive the work from a queue rather than a list
Put the pending items in a work queue or a Dataverse table with a status, an attempt count, and a result. The flow takes the next item, processes it, and writes back what happened. That single change gives you restartability, a natural retry policy, visibility into what is stuck, and an audit trail, and it removes the class of bug where a rerun processes the first two hundred records again.
Rebuild every recorded selector by hand
Open the UI elements repository and edit each selector in the custom editor. Trim the ancestor chain to the shortest reliable path, keep attributes that identify the element by what it is, remove index and position based conditions, and use contains, starts with, or a regular expression wherever part of a value is dynamic. Then test each element against a second instance of the application with different data in it, because a selector that only matches your test record is not a selector, it is a coincidence.
Replace every fixed delay with a wait and a timeout
Search the flow for wait actions with a hardcoded duration and replace them with the condition you were really waiting for: the window exists, the element contains text, the page finished loading, the file appeared. Set a timeout on each one and route the timeout into your error path rather than letting the flow carry on into an action that will fail more confusingly two steps later. Set action level timeouts as well so a single hung action cannot hold the machine indefinitely.
Add error handling and a cleanup subflow
Configure error handling on each block: retries with an interval for transient problems, an immediate stop with a recorded reason for data problems. Write one cleanup subflow that closes every application the flow opened, clears temporary files, and leaves the desktop in the state the next run expects, then make sure every exit path goes through it. Capture a screenshot and the last known step in the error path so the failure record explains itself.
Move credentials into a vault and out of the flow
Remove every typed password, connection string, and API key from the flow. Store them in Azure Key Vault or the enterprise vault you already run, retrieve them in the calling cloud flow, and pass them to the desktop flow as sensitive input variables so they are masked in the run history. Give the machine group a dedicated service account with least privilege, and agree the rotation process with whoever owns identity before go live rather than after the first expiry.
Prepare the machine group the way you would prepare a server
Use dedicated machines with no interactive users, put them in a machine group so runs queue and fail over, and set the screen resolution and scaling for unattended runs explicitly in the machine settings. Standardize the image: the same runtime version, the same application versions, the same browser with the extension installed and its updates on a controlled schedule, the same regional and locale settings. Document the image, because reproducing it is what you will need on the day one machine starts behaving differently from the rest.
Instrument the run and alert on failure
Write a structured log line for each item and each stage, either to your work queue table or to a dedicated logging table in Dataverse. Build a cloud flow that fires on a failed desktop flow run and notifies the owning team with enough context to act. Add a scheduled reconciliation that compares expected volume against processed volume and raises a flag on a mismatch, so a run that finishes successfully without doing the work is caught the same day.
Test as an unattended run under production conditions, then promote through solutions
Run the flow unattended on the target machine group, with the service account, at the resolution and locale production will use, against realistic data volumes and including the awkward cases: an unexpected dialog, a slow response, a record that is already processed, a mid run restart. Only then package it in a solution with environment variables and connection references, promote it through test to production, and keep watching the run history and the reconciliation for the first full cycle of the business process.
Production readiness checklist
Labels move between releases of Power Automate Desktop and the Power Automate portal, so this table is organized by what each control protects against rather than by the exact wording on your screen. If you cannot point at where a row is handled in your automation, that is your next piece of work.
| Control | Where it is configured | What it protects against |
|---|---|---|
| Hand written selectors in the UI elements repository | The desktop flow itself, in the custom selector editor | An application or browser update that moves, renames, or reorders the element the recorder happened to capture. |
| Wait for window, element, page content, or file, each with a timeout | Waiting actions in the desktop flow, in place of fixed delays | Timing failures on a slow day, and hung runs that hold a machine because nothing ever appeared. |
| Error handling per block, with retry count and interval | Block and action settings in the desktop flow designer | One transient failure ending an entire run, and data errors being silently retried when they should stop. |
| Cleanup subflow on every exit path | A dedicated subflow called from the error and completion paths | The next run inheriting open applications, locked files, and dialogs left behind by the last one. |
| Work queue or state table with per item status and attempt count | Dataverse, read and written by the cloud flow and the desktop flow | Duplicate or skipped work after a restart, and having no answer to the question of what is stuck. |
| Secrets in a vault, passed as sensitive input variables | Azure Key Vault or your enterprise vault, retrieved by the calling cloud flow | Credentials living in the flow definition, travelling with every export, and appearing in run history. |
| Screen resolution and scaling for unattended runs | Machine settings in the Power Automate portal | Image based and coordinate based actions behaving differently from the attended run you tested. |
| Machine group with queuing and more than one machine | Machine groups in the Power Automate portal | Runs missing their window behind a long job, and a single machine outage stopping the process. |
| Controlled update schedule for Windows, applications, and browsers | The machine image and endpoint management, not the Power Platform | An overnight browser or application update breaking automation before anybody is at a desk. |
| Failure alerting and business reconciliation | Cloud flows over the desktop flow run data in Dataverse | A failing automation going unnoticed, and a run that completes successfully while processing nothing. |
| Solutions, environment variables, and connection references | Power Platform ALM, with the solution in source control | Fixes made directly in production, and a process nobody can rebuild in a new environment. |
Two of these rows are not owned by the Power Platform team at all. The machine image and the update schedule belong to end user computing, and the vault and the service account belong to whoever runs identity. Agreeing those two before go live prevents most of the arguments that happen after the first production incident.
How we build and run this for clients
Solzet is a Microsoft Dynamics 365 Customer Engagement and Power Platform consultancy in Yerevan, Armenia. We build Power Automate cloud flows, desktop flows, and custom connectors, and a good share of our automation work is hardening flows somebody else built that stopped being trustworthy. The pattern is consistent: the process was recorded rather than designed, so the selectors are brittle, the waits are guesses, there is no state to restart from, and nobody finds out about a failure until the business does. We rework those in the order set out above, and we keep the desktop portion of a process as small as the systems allow.
We work inside Dynamics 365 Customer Engagement and the Power Platform only: Sales, Customer Service, Field Service, model driven and canvas apps, Power Automate cloud and desktop flows, Power Pages, Dataverse, plug-ins and custom APIs, and PowerApps Component Framework controls. We do not take on Business Central or Finance and Operations work, so if your automation sits in those products we will say so at the first conversation.
The wider service is described under Power Automate and RPA consulting. If the problem is less about one flow and more about an estate of them, our nearshore Power Apps Center of Excellence page covers governance and standards across an environment, and Power Platform development and support from Armenia covers the ongoing model. Where the automation is one symptom of a Dynamics 365 implementation that has gone wrong, the rescue and takeover guide describes how we pick that up.
Frequently Asked Questions
Is Power Automate Desktop reliable enough for production RPA?
Yes, with proper design. Power Automate Desktop runs unattended production processes perfectly well, and the flows that fall over are almost always the ones built the way the recorder produced them: recorder selectors, fixed delays, no error handling, no state, and no monitoring. A desktop flow built the way you would build any other production integration, with hand written selectors, waits that check a condition, retry and cleanup logic, a work queue behind it, secrets in a vault, and alerting on failure, is as dependable as the applications it drives. The reliability question is really a design question.
Why does my desktop flow work attended but fail unattended?
Because an attended run borrows your session and an unattended run creates its own. Yours has your screen resolution and scaling, your already open applications, your warm browser profile, and your regional settings. The unattended session has whatever the machine settings define, nothing open, and no console user. Anything that depended on an application already running, on a specific pixel position, or on an image looking the way it does on your monitor will behave differently. An unattended run also needs to take the session on the machine, so it fails if somebody is signed in there. Test unattended on the target machine group from the beginning rather than at the end.
What is the most common cause of desktop flow failures in production?
Selectors, by a distance. The recorder captures the whole element hierarchy plus whatever attributes were present, including positional indexes and generated identifiers, so the selector encodes where the element was on the day you recorded it rather than what the element is. The next release of the application moves it and the flow breaks. The fix is unglamorous and permanent: rebuild each selector in the custom editor against stable attributes, use contains, starts with, or a regular expression for anything dynamic, and test the element against a second record before you ship it.
How should error handling and retries work in a desktop flow?
Set error handling per block rather than relying on one wrapper around the whole flow. Transient problems such as a slow load, a temporarily locked file, or a network blip deserve a small number of retries with an interval between them. Data problems such as a missing record or a rejected value should stop that item immediately with a recorded reason, because retrying them just wastes the window. Every exit path, successful or not, should run a cleanup subflow that closes applications and leaves the machine in a known state, and the error path should capture a screenshot so the failure record explains itself.
How do I stop a desktop flow from processing the same records twice?
Stop iterating over a list and start consuming a queue. Put pending items in a Power Automate work queue or a Dataverse table with a status, an attempt count, and a result, and have the flow claim an item, process it, and write back the outcome. A restart then resumes instead of starting over. Add an idempotency key on the target side, so if the same item is replayed after a failure that happened halfway through, it updates the record it already created rather than creating a second one.
How do I monitor unattended desktop flows in production?
Desktop flow runs are stored in Dataverse, so the run history is data you can query and build on rather than just a screen somebody has to remember to open. Build a cloud flow that fires on a failed run and notifies the owning team with the flow name, the machine, the failing item, and the error. Log each item and stage from the flow itself into your queue or a logging table. Then add the check that catches the quiet failures: a scheduled reconciliation comparing what should have been processed against what was, so a run that completed successfully while doing nothing is flagged the same day.
Should I use a desktop flow or a cloud flow?
Use a cloud flow whenever the system exposes an API, a connector, or a database, and use a desktop flow only where there is genuinely no way in but the screen. Cloud flows do not care what a window looks like, so they do not break when the vendor ships a new layout. In most of the processes we automate the answer is both: a cloud flow orchestrates the process, manages the queue, handles the systems that have connectors, and calls a small desktop flow for the one legacy application that has no other entry point. Keeping that desktop portion as small as possible is the most durable reliability decision in the whole design.
Can Solzet build and support unattended Power Automate Desktop flows for us?
Yes. Solzet is a Microsoft Dynamics 365 Customer Engagement and Power Platform consultancy based in Yerevan, Armenia. We design and build cloud flows, desktop flows, and custom connectors, and we harden existing automations that have become unreliable: reworking selectors, adding error handling and cleanup, putting a work queue behind the process, moving credentials into a vault, setting up machine groups and monitoring, and bringing the whole thing under solution based ALM. We work directly with end clients and white-label for Microsoft partners across Europe and the US.
Automations you cannot rely on? We will make them boring.
Send us the flow that keeps failing and we will work it through selectors, waits, error handling, state, machines, and monitoring until it stops being an incident. Solzet delivers Power Platform and Dynamics 365 Customer Engagement work from Yerevan, Armenia, directly for end clients and white-label for Microsoft partners across Europe and the US.