Power Automate flow failures explained

Flow failures fall into four families: the flow ran and an action failed; the flow ran and an expression could not be evaluated; the flow was throttled, suspended, or lost its connection; or the flow never ran at all. The run history tells you which, if you know where to look. This reference covers the recurring errors in each family with the fix. Design-level patterns for making flows fail safely are in Power Automate error handling patterns; detecting failures before users do is in error monitoring.

Reading a failed run

Open the run, expand every scope and loop until you reach the action with the red icon, and read its Outputs pane: the status code, the error body, and — for connectors — the request the connector actually sent. The message at the top of the run is a summary of a summary; the action's raw output is the truth.

Actions that failed

"ActionFailed. An action failed. No dependent actions succeeded."

Symptom. A scope, condition, or Apply to each shows failed with this text.

Cause. A child action failed and the container reports it. Also appears when every branch of a condition was skipped because the actions were configured to run only on success of something that failed.

Fix. Drill into the container; fix the actual failing action. Check Configure run after on actions that should run on failure.

"BadGateway" / 502 / "The service is unavailable" / 503

Symptom. A connector action fails with a gateway status; a retry an hour later works.

Cause. The connector's backend, the on-premises data gateway, or the target service was unavailable or timed out. On the gateway, it often means the gateway machine is off, out of memory, or its service account's password expired.

Fix. Resubmit the run. If it recurs, check the gateway's status in the admin centre and the target service's health; add a retry policy (Settings on the action) with exponential backoff.

Prevention. Default retry policy on every action that talks to a network; gateway clusters rather than single machines for on-premises sources.

"The response is not in a JSON format."

Symptom. An HTTP action or a custom connector fails parsing.

Cause. The endpoint returned HTML (a login page, an error page), an empty body, or XML. Typically an expired token, a wrong URL, or an API that returns 204 No Content.

Fix. Look at the raw body in Outputs. Fix the authentication or URL; for legitimate non-JSON responses, read body() as text or use the Parse JSON action only when there is content.

"OpenApiOperationParameterValidationFailed" / "Input parameter 'X' is required"

Cause. A required field on the action is empty at runtime — a dynamic content token that resolved to nothing.

Fix. Trace the token back to its source action and see why it was empty; add a condition or a coalesce() default.

Dataverse: "Resource not found for the segment 'X'." / "Could not find a property named 'X' on type 'Microsoft.Dynamics.CRM.account'."

Symptom. A List rows, Get a row, or Update a row action fails with an OData message.

Cause. The table name in the URL segment is wrong (it wants the plural entity set name, accounts, not account), or a column in Filter rows, Select columns, or Expand query is not the lowercase logical name. Lookups in filters need the _value form: _parentcustomerid_value eq '…'.

Fix. Use exact logical names from the table's Columns view; test the filter in the browser against /api/data/v9.2/ first.

Prevention. FetchXML vs OData covers both query languages; use FetchXML for anything with joins.

Dataverse: "A record with the specified key values does not exist" — 0x80040217 / "Does Not Exist"

Cause. Get a row with a GUID that was deleted, a wrong table, or a value that is not a GUID at all (a name pasted into an id field).

Fix. Check the value flowing into Row ID; use an alternate key when you only have a business key.

Dataverse: "Number of requests exceeded the limit of 6000 over time window of 300 seconds" — 0x80072322, HTTP 429

Symptom. Dataverse actions fail under load, often in an Apply to each.

Cause. Dataverse service protection limits per user: 6,000 requests per five minutes, 52 concurrent requests, and 20 minutes of combined execution time per five minutes. A flow that loops over thousands of rows calling Get and Update for each hits it.

Fix. Reduce calls: use Expand query instead of a Get per row, filter at the source, batch with the Dataverse unbound action or a plug-in. Add a retry policy that respects Retry-After. Consider plug-ins for genuinely high-volume work.

Prevention. Design for the limits: batch operations in the Dataverse Web API and the platform's request allocations.

Connector: "Rate limit is exceeded. Try again in X seconds." — 429

Cause. The connector's own throttle (Office 365 Outlook, SharePoint, Excel Online each have per-minute caps per connection).

Fix. Same as above: fewer calls, retry with backoff, spread work over multiple connections or time.

Expressions that could not be evaluated

"InvalidTemplate. Unable to process template language expressions in action 'X' inputs at line '1' and column 'N': …"

Symptom. The action fails before running; the error quotes an expression.

Cause. The rest of the message says which: "The template language function 'int' expects its parameter to be an integer or a string" (type mismatch), "property 'body' doesn't exist" (a token referencing an action that was skipped or returned nothing), "The template language expression cannot be evaluated because property 'value' cannot be selected" (indexing into null), "The template function 'formatDateTime' expects…" (a null date).

Fix. Wrap risky reads in coalesce() or if(empty(...)); check the run-after configuration so the action does not run when its source was skipped; use the ? operator for optional properties (body('Get')?['field']).

Prevention. Assume every dynamic token can be null on real data.

"The execution of template action 'Apply_to_each' failed: the result of the evaluation of 'foreach' expression … is of type 'Null'. The result must be a valid array."

Cause. The array fed to Apply to each is null — the List rows returned nothing, or the token points at a property that does not exist.

Fix. Feed the loop coalesce(outputs('List_rows')?['body/value'], json('[]')), or add a condition on length() before the loop.

"ExpressionEvaluationFailed"

The same family as InvalidTemplate, raised at evaluation time. Read the detail; the fix is identical.

Connections, licences, and policy

"Unauthorized" / "ConnectionAuthorizationFailed" / "The connection is not authenticated"

Symptom. Every run of a flow fails at the first connector action; the connection shows a warning in Data > Connections.

Cause. The connection's token expired or was revoked — a password change, MFA policy change, the owner leaving the organisation, or a service principal secret expiring.

Fix. Re-authenticate the connection, or better, repoint the connection reference to a service account's connection.

Prevention. Solution-aware flows with connection references owned by a service account, and secrets in Key Vault with expiry alerts.

Flow owner left the organisation

Symptom. Flows fail with connection errors, or are turned off, after a leaver's account is disabled.

Cause. The flows and their connections belonged to a person.

Fix. Add a co-owner or reassign ownership through the admin centre's flow management; recreate connections under a service account.

Prevention. Every production flow in a solution, owned by a service account, with the team as co-owners.

"This flow is suspended because it violates a DLP policy" / "Flow suspended"

Cause. A DLP policy now classifies two of the flow's connectors in different groups (Business and Non-Business), or blocks one of them. Also suspended when a premium connector is used and the owner's licence lapsed.

Fix. Change the connectors to comply, request a policy exception, or fix the licence. The admin centre's policy report shows which rule was hit.

Prevention. Check the environment's DLP policy before designing a flow with a new connector; DLP policies in Power Platform explains the groups.

"Flow run timed out" / approval never returned

Cause. A cloud flow run cannot exceed 30 days. An approval or a Delay until that waits longer than that fails.

Fix. Redesign long waits: record the pending state in Dataverse and use a second flow triggered by the response, or a scheduled reminder that escalates.

The flow that never ran

Dataverse trigger does not fire

Cause. In order of likelihood: the trigger's Scope is User or Business unit and the change came from someone outside it; Select columns lists columns that did not change; Filter rows excludes the row; the flow is turned off; the trigger is on the wrong table (a lookup update on the child does not fire the parent's trigger).

Fix. Set Scope to Organization for integration flows; verify the column and filter settings; check the flow's state and the trigger's history in Analytics.

Scheduled flow ran at the wrong time or not at all

Cause. Time zone on the recurrence is UTC by default; daylight saving shifts local times; the flow was turned off for inactivity in a trial environment.

Fix. Set the time zone on the Recurrence trigger explicitly; move production flows out of trial environments.

"Trigger failed" in run history

Cause. The trigger's own call failed — a polling trigger on a connector that throttled or a service that was down. The run is logged as a trigger failure with no actions.

Fix. Usually self-healing on the next poll; recurring trigger failures mean the connection or the source needs attention.

When it is not the flow's fault

A flow that calls Dataverse and gets a business error back — "The record already exists", a plug-in's InvalidPluginExecutionException, a privilege error — is reporting a Dataverse problem. The error body contains the Dataverse message and code; look them up in Dataverse Web API errors and Dataverse plug-in exceptions. Likewise a Business Central connector error carries the BC API message — Business Central API errors decodes those.