Power Automate Flow Failures: Troubleshooting Guide

How to Read a Failed Flow Run

Before diving into specific errors, here is the fastest way to diagnose any flow failure:

1. Go to My flows and click the flow name.
2. Click on the failed run in the run history.
3. The failed action will be highlighted in red. Click on it.
4. Expand Show raw inputs and Show raw outputs — this is where the actual error detail lives.
5. Check the Status code (e.g., 400, 401, 403, 429, 500) and the error message in the outputs.

The run history also shows how long each action took, which helps identify timeout and performance issues.

---

”ActionFailed. The execution of template action ‘action_name’ failed”

The error: “ActionFailed. The execution of template action ‘Send_an_email_(V2)’ failed: the result of the evaluation of ‘foreach’ expression ‘@triggerOutputs()?[‘body/value’]’ is of type ‘Null’. The result must be a valid array.”

What causes it: An action earlier in the flow returned null or unexpected output, and a downstream action is trying to use that output. The most common scenario is an Apply to Each loop receiving null instead of an array.

How to fix it:

1. Check the trigger output or the previous action’s output. If the data source returned no results, the value might be null rather than an empty array.
2. Add a Condition before the Apply to Each to check if the output is not null and not empty:

@not(empty(triggerOutputs()?['body/value']))

3. If the trigger is “When an item is created or modified” and the item was deleted before the flow ran, the trigger output will be empty. Add error handling for this case.
4. Initialise variables with default values at the top of the flow rather than relying on outputs always being populated.

---

”429 Too Many Requests” (Throttling)

The error: Status code 429 with message “Rate limit is exceeded. Try again in X seconds.” or “Too Many Requests.”

What causes it: The connector’s API rate limit has been exceeded. This commonly happens when:

• A flow with an Apply to Each loop makes many rapid calls to the same connector
• Multiple flows share the same connection and collectively exceed the limit
• A scheduled flow runs too frequently during peak hours

How to fix it:

1. Reduce concurrency: Go to the Apply to Each settings and set Degree of Parallelism to 1. This processes items sequentially instead of 20 at a time.
2. Add a Delay action: Inside loops, add a Delay of 1-3 seconds between iterations.
3. Configure retry policy: On the failing action, go to Settings > Retry Policy and set it to Exponential Interval with a higher count (8) and longer minimum interval (PT30S).
4. Batch operations: Use batch endpoints where available (SharePoint $batch, Dataverse ExecuteMultiple).
5. Spread the load: If this is a scheduled flow, stagger run times to avoid overlapping with other flows.

See the Connector Throttling & API Limits reference on this site for specific limits per connector.

---

”The connection ‘abc123’ is not valid” or “Expired connection”

The error: “InvalidConnectionReference. The connection ‘shared-sharepointonl-abc123’ is not valid and the workflow owner doesn’t have permissions for it.” Or: “The caller does not have permission for this connection.”

What causes it: The connection used by the flow has expired, been deleted, or the owner’s credentials have changed. This is one of the most common flow failures in organisations because:

• The flow owner changed their password (breaks shared connections)
• An admin disabled the flow owner’s account
• MFA token expiry forced a re-authentication
• The connection was manually deleted in the connections list

How to fix it:

1. Go to make.powerautomate.com > Connections and look for connections with a warning icon.
2. Click the broken connection and select Fix connection — this re-authenticates with fresh credentials.
3. Open the flow in edit mode, click on the affected action, and select the repaired connection from the dropdown.
4. Save and test.

Prevention: For production flows, use a dedicated service account that does not require MFA (with conditional access exceptions approved by IT). Better yet, use Dataverse service principal connections where supported — they do not expire with password changes.

---

”InvalidTemplate. Unable to process template language expressions”

The error: “InvalidTemplate. Unable to process template language expressions in action ‘Compose’ inputs at line ‘1’ and column ‘35’: ‘The template language expression ‘items(‘Apply_to_each’)?[‘field’]’ cannot be evaluated because property ‘field’ doesn’t exist…’”

What causes it: An expression references a property that does not exist in the data. This happens when:

• The JSON property name is misspelt or uses the wrong case
• Dynamic content was selected from the wrong action
• The data source schema has changed since the flow was built
• The trigger output structure differs from what you tested with

How to fix it:

1. Click on the failed action and check Show raw inputs to see exactly what expression was evaluated.
2. Add a Compose action before the failing action and set its input to the parent object (e.g., triggerOutputs()?['body']). Run the flow and inspect the Compose output to see the actual property names.
3. Fix the property name in the expression. JSON property names are case-sensitive — firstName is not the same as FirstName.
4. Use the safe navigation operator ? to handle missing properties gracefully:

items('Apply_to_each')?['optionalField']

This returns null instead of throwing an error.

---

”BadRequest. The request to the connector failed”

The error: “BadRequest” (HTTP 400) from a connector action, often with a message like “The request body is not valid JSON” or “A required field is missing.”

What causes it: The data you are sending to the connector does not match what the API expects. Common causes:

• A required field in the action is empty
• A field has the wrong data type (sending text where a number is expected)
• Special characters in text fields that break JSON formatting
• Date values in the wrong format

How to fix it:

1. Check Show raw inputs on the failed action — this shows the exact JSON payload sent to the API.
2. Verify all required fields are populated. If a field comes from dynamic content, ensure it is not null.
3. For date fields, use formatDateTime to ensure the correct format:

formatDateTime(triggerOutputs()?['body/StartDate'], 'yyyy-MM-ddTHH:mm:ssZ')

4. For text fields with special characters, use replace to escape problematic characters or the encodeUriComponent function for URL parameters.
5. If the connector action has an option to show “advanced parameters”, check if a newly required field needs a value.

---

”The approval has timed out”

The error: Flow shows as “Running” indefinitely, then eventually fails with “ActionTimedOut” on the “Start and wait for an approval” action, or the approval response never arrives.

What causes it:

• The approver never received the notification (email went to spam, Teams notification was missed)
• The flow run exceeded the 30-day maximum run duration
• The approval was assigned to a group mailbox or distribution list that cannot respond
• The approver’s licence does not include Dataverse access (approvals require Dataverse)

How to fix it:

1. Check whether the approval was actually created: go to make.powerautomate.com > Action items > Approvals and look for the pending approval.
2. If the approval exists but the email was not received, check the approver’s spam/junk folder.
3. Set a timeout on the approval action: go to Settings > Timeout and set something like P7D (7 days). After the timeout, use a Condition to handle the “no response” case.
4. For critical approvals, add a follow-up reminder: use a parallel branch with a Delay followed by a reminder email.
5. Verify approvers have an appropriate licence that includes Dataverse access.

---

”WorkflowRunWasCanceled. The workflow run was canceled”

The error: “WorkflowRunWasCanceled” or “The workflow run was canceled by the owner.”

What causes it:

• Someone manually cancelled the flow run from the run history
• The flow was turned off while it was mid-run
• The flow was deleted while it had active runs
• A child flow (called via “Run a Child Flow”) was cancelled
• The trigger condition evaluated to false after the trigger fired (for certain trigger types)

How to fix it:

1. Check the run history — if the status is “Cancelled” rather than “Failed”, someone intervened manually.
2. If flows are being cancelled during deployments, establish a process to drain active runs before updating flows.
3. For child flows, check the child flow’s run history independently — it will have its own error details.
4. If you see recurring cancellations on automated flows, check whether the trigger is configured with a trigger condition that intermittently evaluates to false.

---

Parallel Branch Failures

The error: One branch in a Parallel Branch completes successfully, but another fails — and the entire flow is marked as failed.

What causes it: By default, if any parallel branch fails, the flow is marked as failed even though other branches succeeded. The actions in successful branches still executed.

How to fix it:

1. Add a Configure run after setting on the action immediately after the parallel branches. Click the ... menu > Configure run after and select all four options: “is successful”, “has failed”, “is skipped”, “has timed out”.
2. Inside each branch, wrap risky actions in a Scope and add error handling after the scope.
3. Use the result() function after the parallel branches to check which branches succeeded:

result('Branch_1_Scope')?[0]?['status']

---

Null Reference in Expressions

The error: “The execution of template action failed with error: ‘The template language function ‘split’ expects its first parameter to be of type string. The provided value is of type ‘Null’.’”

What causes it: An expression function received null instead of the expected type. This happens when:

• A dynamic content field is empty for certain records
• A preceding action was skipped (due to conditional logic) and its output is null
• The trigger payload is missing expected fields

How to fix it:

1. Use coalesce to provide a fallback value:

split(coalesce(triggerOutputs()?['body/Tags'], ''), ';')

2. Add a Condition to check for null before processing:

@not(equals(triggerOutputs()?['body/Tags'], null))

3. Use the null-safe ? operator on all property access paths.
4. Initialise variables with sensible defaults at the start of the flow.

---

”Forbidden. The caller does not have the required permissions”

The error: “Forbidden” (HTTP 403), “The caller does not have the required permission” or “Access is denied.”

What causes it:

• The connection owner does not have permissions to the target resource
• A Dataverse security role is missing the required privilege
• The SharePoint list or library has unique permissions that exclude the flow’s user
• The flow is trying to access a resource in a different tenant

How to fix it:

1. Identify which account the connection uses (check the connection details — it shows the signed-in user).
2. Verify that account has the necessary permissions directly in the target system (SharePoint site, Dataverse environment, mailbox, etc.).
3. For Dataverse, ensure the user has a security role with the required table privileges (Create, Read, Write, Delete as needed).
4. For cross-tenant scenarios, ensure the external connection or guest account is properly configured.
5. Test by signing into the target system as the connection user and performing the same operation manually.

---

Trigger Conditions Not Firing

The error: Not an error per se — the flow simply never runs, even when you expect it to.

What causes it:

• The trigger condition expression evaluates to false for all events
• The trigger is polling-based and the polling interval has not elapsed
• The flow is turned off
• The connection used by the trigger has expired
• For SharePoint “When an item is created or modified”, the modification did not change a column that SharePoint considers a “real” change (e.g., view count updates do not trigger flows)

How to fix it:

1. Check that the flow is turned on (this sounds obvious, but it is the number one cause).
2. Check the trigger connection — if the connection is broken, the trigger silently stops checking.
3. For trigger conditions, test the expression in a Compose action using sample data to verify it evaluates to true.
4. Check the trigger’s run history — even skipped triggers appear here with status “Skipped” and the reason.
5. For SharePoint triggers, verify the flow owner has at least Read access to the list.
6. Try editing the flow, re-selecting the trigger parameters, saving, and turning it off and on again. This resets the trigger’s internal state.

---

General Troubleshooting Checklist

When a flow fails and none of the above errors match exactly:

1. Read the raw outputs — always expand the failed action’s raw inputs and outputs.
2. Check the status code — 400 (bad request), 401 (auth), 403 (permissions), 404 (not found), 429 (throttled), 500 (server error).
3. Test the action in isolation — create a new flow with just the failing action and hardcoded inputs.
4. Check the connections — go to Connections and verify all are healthy.
5. Review recent changes — did someone update the flow, change the data source, or modify permissions?
6. Check Power Platform service health — the admin centre shows current outages and degradation.
7. Search the error message — paste the exact error text into your search engine. The Power Automate community forums are surprisingly helpful.