PL-500 common mistakes
PL-500 · Understand the traps and how to avoid them.
Builds the desktop flow directly in the recorder against the happy path only, without ever writing down what should happen for business exceptions such as record not found, duplicate invoice, or validation failure, so the delivered flow has no exception branches.
The successful demo path is what is easiest to record in a dev environment; exception behaviour has to be extracted from the process owner and feels like non-automatable work.
What to do instead
Before building, produce an exception matrix separating expected/business exceptions from unexpected/system exceptions, and for each one decide whether to retry, skip and continue, log, or escalate (approval or Teams notification). Design the flow branches around that matrix.
Designs an unattended desktop flow that at runtime requires a person to read a screen, enter a one-time code, dismiss a dialog, or approve a step.
Confusing 'runs without me watching' with 'runs without any human involvement', because the recorder always works in an attended interactive session.
What to do instead
Classify each run as attended or unattended and remove blocking UI prompts from unattended paths; move human decisions into an approval or adaptive card step in the cloud flow that runs before the desktop flow, and verify the process can complete with no interactive session.
Keeps the recorded actions unchanged: fixed Wait of a few seconds before every step, clicks by screen coordinates or images, and selectors tied to localized window titles or positions.
The recorder generates actions that work on the developer's machine at one resolution in one session, which looks successful during the first test run.
What to do instead
Replace fixed delays with Wait for window / Wait for UI element actions, capture elements into the UI elements repository using stable attributes, add anchors where attributes are ambiguous, use dynamic selectors built from variables, and retest at different resolutions, zoom levels, and in a locked or disconnected session.
Writes flows with no On block error handling, no Retry, and no Terminate, so any failing step silently ends the run and nobody knows which record was being processed.
Error handling is deferred as extra effort once the flow already works on good input.
What to do instead
Wrap risky steps in On block error, use Retry for transient failures such as slow page loads, capture the current item identifier and error details into Dataverse or a log file, and end with either Terminate carrying a clear message or a controlled continue to the next item in the loop.
Hardcodes passwords, API keys, or connection strings inside Set variable or Type into actions, or stores them in a text file or a variable that appears in run history.
It is the fastest way to get the flow running locally, and the developer's own account credentials are already available on the dev machine.
What to do instead
Store secrets in Azure Key Vault, retrieve them in the orchestrating cloud flow, and pass them to the desktop flow as input variables with secure inputs enabled, or use the Power Automate credential store; never write secrets into actions that log values.
Publishes a solution whose flows use HTTP, custom connectors, or the desktop flow module without ever checking the target environment's data loss prevention policies, and the flows are blocked or cannot run after import.
The developer environment often has permissive or no DLP policies, and desktop flows plus the desktop flow module are connectors that are subject to DLP classification just like any other connector.
What to do instead
Inventory every connector the solution uses, including the desktop flow module and any custom connectors, confirm how each is classified in the target environment's DLP policy, and get misclassified connectors corrected before deployment rather than after a failed run.
Hardcodes the machine or machine group name, the work queue name, and site or environment URLs directly in the Run a flow built with Power Automate for desktop action, so the same solution points at the wrong machine after deployment to test or production.
It works in the developer environment where the only machine is the developer's own device.
What to do instead
Define these values as environment variables and connection references inside the solution, reference them from the action instead of literal strings, and set the per-environment values during solution import.
Registers a single machine with a single gateway and considers unattended execution configured, then runs fail with machine unavailable or gateway offline, or runs pile up and conflict when several are started at once.
Unattended execution depends on the machine being registered and connected to the environment plus a gateway, and high availability requires more than one machine and gateway in a cluster.
What to do instead
Use a machine group containing multiple machines behind a gateway cluster, verify each machine shows as connected and has valid credentials, and review run queue and concurrency behaviour under realistic load rather than a single test run.
Tries to attach a 'when an email arrives' or SharePoint item-created trigger directly to a desktop flow, or expects a desktop flow to run on a schedule by itself.
Desktop flows look like other flows in the portal but have no triggers of their own; every desktop flow is invoked by a cloud flow.
What to do instead
Design the cloud flow as the orchestrator (trigger, retrieve and shape the data, call the desktop flow, handle the returned output), use the Run a flow built with Power Automate for desktop action, and select the correct attended or unattended run mode for the scenario.
Passes data between a cloud flow and a desktop flow with mismatched types, for example feeding a list of Dataverse rows into an input variable declared as text, or expecting a result back without ever declaring an output variable in the desktop flow.
Desktop flow inputs and outputs are explicitly typed and must be declared on the desktop flow side, and there is no implicit conversion for lists, records, or datatables.
What to do instead
Declare input and output variables with matching types on both sides, initialize and convert values inside the desktop flow (parse JSON or split text into a list, build a datatable), and test each flow in isolation with sample inputs before connecting them.