How to Troubleshoot Power Automate Flows (2026)
Why Power Automate Flows Break (And Why the Errors Make No Sense)
I've seen it happen to nearly every team that adopts Power Automate: a flow runs perfectly for weeks, sometimes months, then one morning it just stops. No warning. No obvious change. Just a red "Failed" status in the run history and an error message that reads something like "The expression 'triggerBody()['value']' is not valid" or, worse, a completely blank error with status code 500. I know how infuriating that is , especially when the flow is the backbone of an approval process or a data sync your whole department depends on.
Power Automate troubleshooting is tricky for a few reasons that Microsoft doesn't explain well in their own interface. First, Power Automate is a cloud-hosted orchestration service , it's not running on your machine. That means local network conditions, firewall rules, or even a brief Azure regional outage can silently kill a flow run without giving you actionable diagnostic data. Second, connectors are individually versioned services. When Microsoft updates the SharePoint connector, the Teams connector, or the Dataverse connector, your existing flow actions may stop matching the new API contract, even though you changed nothing.
Third, and this catches enterprise users off guard, connections are tied to the identity of the person who created them. The moment that person's account is disabled, their password changes, their MFA token expires, or their license is reassigned, every flow using their connection silently loses its authentication. The flow itself looks healthy. The connection looks green. But at runtime, it throws a 401 Unauthorized and you spend two hours debugging the wrong thing.
Then there's the licensing layer. Power Automate has changed its licensing model several times since 2022, and what worked under a Microsoft 365 E3 plan a year ago may now require a standalone Power Automate Premium license (formerly Power Automate per user). Premium connectors, things like HTTP, Azure SQL, SAP, Salesforce, will silently fail if the flow owner's license is downgraded.
Who runs into Power Automate flow failures most often? In my experience: IT admins who inherited flows built by someone who left the company, business users whose approval flows stopped routing correctly after a SharePoint migration, and developers whose scheduled flows started missing trigger windows after an environment was moved between regions. If any of those sound familiar, you're in the right place. Browse all Microsoft fix guides →
The frustrating reality is that Microsoft's own error messages in Power Automate are written for engineers, not for the people who actually build flows every day. "BadGateway", "ServiceUnavailable", and "ConnectionAuthorizationFailed" tell you almost nothing about what actually went wrong or how to fix it. That's what this guide is for.
The Quick Fix, Try This First
Before you spend an hour digging through logs, do this. It resolves a surprisingly high percentage of Power Automate flow failures, I'd estimate somewhere around 60% of the cases I've seen.
Step 1: Open the failed flow run and read the exact failed action. Go to make.powerautomate.com, click My flows, find your flow, and click the failed run timestamp under 28 day run history. Expand the red-highlighted action. Don't just read the action name, click the orange triangle icon to expand the raw error output. That's where the real message hides.
Step 2: Re-authenticate every connection the flow uses. This is the fix 60% of users need and don't know it. In the flow editor, click Settings (gear icon, top right), then scroll down to see all connections listed. For each one, click the three-dot menu and choose Fix connection. You'll be prompted to sign in again. Do it for all of them, even the ones that show a green checkmark. A green checkmark only means the connection object exists, not that the token is still valid.
Step 3: Save and test. Click Save, then use the Test button (top right of the flow editor) and select Manually. Watch the live run output. If it passes, you're done. If it fails at a different action than before, you've made progress, the connection issue is resolved and now you have a cleaner signal about the real problem.
Step 4: Check if this is a transient Azure outage. Go to status.azure.com and look at the Power Automate row for your region. If there's a yellow or red indicator, wait 30 minutes and test again. Many "mysterious" Power Automate failures are actually Microsoft-side incidents that resolve themselves.
Power Automate troubleshooting always starts here. The run history is your flight recorder, skip it and you're guessing.
Navigate to make.powerautomate.com and sign in with the flow owner's account (important, not just any account). Click My flows in the left sidebar. If the flow is shared with you but you're not the owner, go to My flows > Shared with me tab instead.
Click the flow name to open its detail page. Under 28 day run history, you'll see a table of all recent runs. Failed runs show a red Failed badge. Click the timestamp of the most recent failed run.
This opens the run detail view. Every action in the flow is shown as a collapsed card. The failed action has a red border. Click it to expand it. You'll see two sub-sections: Inputs and Outputs. Expand both. The Outputs section contains the raw error response, this is what you actually need.
Copy the entire error body. Look specifically for these fields:
{
"error": {
"code": "ConnectionAuthorizationFailed",
"message": "The caller with object id '...' does not have permission..."
}
}The code field maps directly to a root cause. Common ones: ConnectionAuthorizationFailed = expired token or wrong account, InvalidTemplate = broken expression, ActionFailed = upstream connector returned an error, Throttled = you've hit API rate limits. Once you know the code, you know which section of this guide to jump to.
If the failed action shows no outputs at all, just a timeout, note the duration shown on the action card. If it shows exactly 120 seconds, you've hit the connector's default timeout threshold, which is a separate issue covered in the Advanced section.
This is the most common fix in Power Automate troubleshooting. Connections break silently all the time, password resets, MFA changes, license reassignments, tenant policy changes. The flow editor shows them as healthy right up until runtime.
Open your flow in edit mode (click the pencil icon on the flow detail page). In the top-right area, click the three horizontal lines (hamburger menu) and then My connections. Alternatively, go directly to make.powerautomate.com/connections.
You'll see all connections associated with your account. Any connection with a warning icon needs immediate attention. But here's the thing, connections without warning icons can also be broken. To be safe, click each connection used by your failing flow and select Edit or Fix connection from the three-dot menu.
For OAuth-based connectors (SharePoint, Teams, Outlook, OneDrive), you'll be redirected to a Microsoft sign-in page. Use the correct account, the one that has permission to the resources the flow accesses. For SQL or custom connectors, you'll need to re-enter credentials manually.
After fixing connections, return to your flow, click Save (even if you made no other changes, this re-binds the connection references), then test. Watch the action that previously failed.
If you see this specific error in SharePoint actions:
The server returned the following error: Unauthorized...the connection account has lost permissions to the SharePoint site, not just the token. You'll need to verify that the connection owner is still a member of the site with at least Contribute permissions in SharePoint Site Settings > Site Permissions.
The second most common source of Power Automate flow failures is broken dynamic content expressions. These usually appear after a trigger or upstream action changes its output schema, which happens when a SharePoint list column is renamed, a form field is deleted, or a connector is updated by Microsoft.
The error signature is usually one of these:
InvalidTemplate: Unable to process template language expressions
The expression 'triggerBody()?['fieldname']' cannot be evaluatedOpen your flow in edit mode. Click on the failed action (from the run history, not the editor, the editor won't mark broken actions). Look at each field in the action that uses dynamic content (shown as blue pill-shaped tags). Hover over each pill. If it shows a red error indicator or the field reads null even when it shouldn't, that expression is broken.
The fix depends on what changed upstream. If a SharePoint column was renamed, open the trigger (usually When an item is created or modified), click the three-dot menu on the trigger, and choose Settings. There's no "refresh schema" button, instead, delete the trigger and re-add it. This forces Power Automate to fetch the current list schema.
Then rebuild the dynamic content references in each broken action. Don't manually type expressions unless you know the exact JSON path. Use the Dynamic content panel (appears when you click in any text field) and re-select the correct fields.
For complex expressions, use the Expression tab in the dynamic content panel to test your syntax:
coalesce(triggerBody()?['Title'], 'No Title')The coalesce() function is your friend, wrap uncertain fields in it so null values don't crash the whole run.
Sometimes a Power Automate trigger is not working, the flow never starts even though the triggering event definitely happened. This is a separate failure mode from action failures, and it's diagnosed differently.
First, check whether the flow is actually turned on. Go to the flow detail page. Under the flow name you'll see either Flow is on (green) or Flow is off (grey). If it's off, someone, or an automated policy, disabled it. Click Turn on.
For automated triggers (like SharePoint "When an item is created"), the trigger uses a polling mechanism. Power Automate polls the source every 1–5 minutes depending on your license. If you're on a Microsoft 365 base license (not a Power Automate Premium license), the polling interval is 5 minutes. Events that happen and resolve within that window can be missed entirely.
Check the trigger history. On the flow detail page, scroll past the run history to find Trigger history. Each line shows whether the trigger fired and whether it was skipped. A "Skipped" status means the trigger evaluated the conditions and intentionally didn't start, check your trigger conditions (filter queries, column conditions) to make sure they match the event that occurred.
For scheduled triggers (Recurrence), check whether the schedule has drifted. Open the trigger, and verify the Start time, Time zone, and Frequency settings. A common issue: the time zone defaults to UTC, so a flow intended to run at 9 AM local time may actually run at 2 AM or 1 PM depending on your offset and DST status.
For HTTP request triggers, the URL is regenerated every time the flow is saved. If an external system is posting to a stale URL, the trigger will never fire. Go to the trigger, copy the updated HTTP POST URL, and update your calling system.
As your Power Automate flows get more sophisticated, processing hundreds of SharePoint items, sending bulk emails, or looping through large datasets, you'll hit throttling. This is one of the more annoying failure modes because the flow runs fine in testing (small data volume) and only breaks in production.
The error signature for throttling usually looks like this:
429 TooManyRequests
Retry-After: 60Or from the SharePoint connector specifically:
The request is throttled. Please try again later.
Microsoft.SharePoint.Client.ServerExceptionPower Automate has built-in automatic retry logic for 429 errors, it will wait the number of seconds specified in the Retry-After header and try again. But if you're hitting the connector's daily action limits, retries won't help.
For Microsoft 365 licensed users, the Power Automate platform limits are: 6,000 actions per day for base Microsoft 365 plans. For Power Automate Premium, this jumps to 40,000 actions per day. Check your consumption in the Power Platform Admin Center at admin.powerplatform.microsoft.com > Resources > Capacity.
To reduce throttling pressure on loops, add a Delay action inside your Apply to each loop:
Action: Delay
Count: 1
Unit: SecondThis slows down iteration but eliminates burst throttling. Also, enable Concurrency control on your Apply to each, go to the three-dot menu on the loop, click Settings, enable Concurrency Control, and set the degree of parallelism to 1 to force sequential processing. This dramatically reduces API pressure.
For SharePoint specifically, replace row-by-row Get items calls with a single Get items action with an OData filter query to pull only the records you need in one request. Fewer API calls equals fewer throttling events.
Advanced Power Automate Troubleshooting
Diagnosing Failures with the Power Platform Admin Center
If you're managing flows across an organization, or if you're a Power Platform admin troubleshooting a flow you don't own, the Power Platform Admin Center is where you need to go. Open admin.powerplatform.microsoft.com, navigate to Analytics > Power Automate. Here you'll find aggregate flow run data, error rates by connector, and environment-level health metrics.
To view specific flow run data for flows you don't own, you need the Power Platform Service Admin or Global Admin role. With that access, go to Environments > select your environment > Resources > Flows. You can see all flows in the environment, their owners, and run history.
Group Policy and DLP Policies Blocking Connectors
Enterprise environments often have Data Loss Prevention (DLP) policies configured in the Power Platform Admin Center. These policies classify connectors into Business and Non-Business groups, and you cannot use connectors from both groups in the same flow. If someone adds a new action using a connector classified in the wrong DLP group, the entire flow fails with:
FlowSave failed with code 'DlpPolicyViolation'
This flow uses connectors across multiple data groupsTo diagnose this, go to admin.powerplatform.microsoft.com > Policies > Data Policies. Review which connectors are in which group for the affected environment. You'll either need to move the connector to the correct group (requires admin rights) or restructure the flow to separate the incompatible connectors into child flows called via the HTTP connector.
Event Viewer for Desktop Flow Failures
If you're running Power Automate desktop flows (formerly UI flows), failures produce logs in the Windows Event Viewer on the machine running the desktop flow. Open Event Viewer (press Win + R, type eventvwr.msc) and navigate to:
Applications and Services Logs > Microsoft > Power Automate Desktop > OperationalLook for Event IDs in the 1000–1999 range. Event ID 1002 specifically indicates a UI element not found error, the desktop flow tried to click a button or field that wasn't present on screen. Event ID 1010 indicates a timeout waiting for an application to respond.
Timeout Errors (120-Second Limit)
Individual actions in Power Automate have a default timeout of 120 seconds. If a single action takes longer, common with large file operations or slow external APIs, it fails with an ActionTimeout error. Some connectors let you configure this. Go to the action's three-dot menu > Settings and look for a Timeout field. Set it in ISO 8601 duration format:
PT5M ← 5 minutes
PT30M ← 30 minutes
PT2H ← 2 hoursThe maximum configurable timeout per action is 24 hours (PT24H). If your operation genuinely needs more time than that, you need to restructure using asynchronous patterns with HTTP webhooks.
Escalate to Microsoft Support when: a flow fails with a 500 Internal Server Error and retrying produces the same result across 24+ hours (this usually means a backend service defect), when a DLP policy change is needed but you don't have admin access, when a connector itself appears broken for your entire tenant (check the Microsoft 365 Service Health dashboard first), or when a flow owned by a deleted user cannot be reassigned through normal means. For Premium support customers, Microsoft targets a 4-hour initial response for Severity B Power Platform issues.
Prevention & Best Practices for Power Automate
Most Power Automate troubleshooting work is avoidable. Here's what I've seen separate teams that rarely have flow failures from teams that are constantly firefighting.
Use service accounts, not personal accounts, for production flows. This is the single highest-impact change you can make. When a human account owns all the connections in a critical flow and that person leaves the company or changes their password, everything breaks at 2 AM. Create a dedicated service account (a licensed mailbox like powerautomate-prod@yourcompany.com), assign it a Power Automate Premium license, and use it exclusively for production flow ownership and connection authentication. Configure the account with a password that never expires and a static MFA method.
Implement error handling in every flow. By default, if any action fails, Power Automate halts the flow and marks the run as failed. You can change this. For critical actions, click the three-dot menu > Configure run after and check has failed. This lets you add a parallel error-handling branch that sends you a notification with the error details instead of silently failing. Use a Compose action with this expression to capture the error:
outputs('YourFailedAction')?['body']Then send that to a Teams channel or email so you know immediately when something breaks and exactly what the error was.
Document ownership and dependencies. Maintain a simple SharePoint list or Excel file that records: flow name, owner, connection accounts used, what it does, and what business process depends on it. When connections need re-authentication or ownership needs to transfer, this list is invaluable.
Test flows with production-scale data. A flow that processes 10 items in testing will behave very differently than one that processes 10,000 items. Before go-live, run load tests using your largest expected data sets. Watch for throttling errors, timeout failures, and memory issues in large Apply to each loops.
- Set a recurring calendar reminder every 60 days to re-authenticate all service account connections, this prevents silent token expiry failures
- Enable email notifications on flow failure (Flow detail page > three-dot menu > Turn on notifications) so you're not waiting for users to report problems
- Use Scope actions to group related steps and add try/catch error handling, it makes your flows dramatically easier to debug
- Keep flow descriptions updated, include the last modified date, what changed, and why, future-you (or your successor) will be grateful
Frequently Asked Questions
Why does my Power Automate flow say "Failed" but I can't find any red action in the run history?
This happens when the failure occurs at the trigger level, not inside the flow body. Open the flow detail page and scroll below the run history to find the separate Trigger history section. If the trigger itself has a failed entry, click it to see the raw error. The most common causes are: the trigger connection expired, a DLP policy change blocked the connector, or the flow was turned off by a co-owner or admin and the trigger never fired. If trigger history shows "Succeeded" but there are no run history entries, your trigger conditions (filter queries, column filters) are filtering out all events, check and loosen those conditions.
My Power Automate approval flow stopped sending approval emails, what's wrong?
Approval emails are sent from the Microsoft Flow service, not from your personal Outlook. The most common reason they stop arriving is that the approver's email address changed (account renamed or migrated), the flow still has the old address hardcoded. Open the flow editor and check the Start and wait for an approval action's Assigned to field. Also check the approver's junk/spam folder, Microsoft's approval emails sometimes get quarantined by aggressive mail filtering. If the flow run history shows the approval action as "Waiting" indefinitely, the approval was sent but simply never responded to, you can cancel the pending approval from the run detail view and re-trigger.
Power Automate is saying I need a Premium license for a connector I've been using for months, what changed?
Microsoft periodically reclassifies connectors from Standard (included in Microsoft 365 licenses) to Premium (requires a standalone Power Automate license). This has happened to several connectors including the HTTP connector, Azure SQL, and several third-party service connectors. If a connector you've been using moves to Premium and you don't have the right license, your flow will fail at runtime with a licensing error. Check the current connector classification at the Power Automate connectors documentation page. Your options are: upgrade to a Power Automate Premium per-user plan (~$15/user/month), or restructure the flow to replace the Premium connector with a Standard alternative, for example, replacing a direct HTTP action with a custom connector built by someone who has a Premium license.
How do I transfer a flow to a new owner when the original owner left the company?
This requires Power Platform admin access. Go to admin.powerplatform.microsoft.com > Environments > select your environment > Resources > Flows. Find the orphaned flow and click the three-dot menu > Edit details or Run as depending on your version of the admin center. You can assign a new owner here. After reassignment, the new owner must open the flow, re-authenticate all connections under their own account, and save the flow. Note: any connections that were exclusively tied to the old account need to be recreated, you can't transfer another user's stored credentials. This is precisely why service accounts are so important for production flows.
My Apply to each loop is running incredibly slowly, how do I speed it up?
By default, Apply to each runs sequentially, one item at a time. For large datasets this can make a flow take hours. Enable parallel processing by clicking the three-dot menu on the Apply to each action > Settings > turn on Concurrency Control and set the degree to 10 (or higher, up to 50). This processes up to 10 items simultaneously. Be careful with high concurrency if your loop makes SharePoint or Dataverse writes, parallel writes to the same records cause conflicts and 429 throttling errors. Also consider whether you actually need a loop at all: many operations that developers implement as per-item loops can be done in a single action using batch operations or OData filter queries that return only the records you need.
Can I see the full inputs and outputs of every action, including sensitive data like passwords?
By default, yes, all inputs and outputs are visible in the run history to anyone who can view the flow. This is a real security concern if your flow handles credentials, PII, or proprietary data. To protect sensitive fields, open the action in edit mode, click the three-dot menu > Settings, and enable Secure Inputs and/or Secure Outputs. When enabled, those values are masked as ***** in the run history. Note that once you enable this, you lose the ability to see those values during debugging, so enable it only after your flow is stable and you've confirmed it works correctly. Admins with Global Admin or Power Platform Admin roles can still view secured values through the Admin Center.