Fix Power Automate Errors: Full Troubleshooting Guide
Why This Is Happening
I've seen this pattern more times than I can count: you build a flow in Power Automate, it works perfectly for weeks, and then one Monday morning everything stops. Your flows are failing, connections show red error badges, and the error messages Microsoft gives you are , let's be honest, nearly useless if you don't already know what you're looking at.
Power Automate troubleshooting is tricky because the platform sits at the intersection of at least three independent systems: Microsoft Entra ID (formerly Azure Active Directory), the specific Microsoft 365 services your flows connect to (SharePoint, Teams, Exchange Online, Excel), and Power Automate itself. When something breaks, the failure can be in any one of those layers, and the error message rarely tells you which one.
Here's the most common scenario I see in enterprise environments. Your IT team rolls out a new Conditional Access policy, maybe a multi-factor authentication requirement for SharePoint, or a Terms of Use agreement that users have to accept before accessing certain services. Nobody tells the Power Automate flows. Those flows have existing connections that were authenticated before the new policy existed. The tokens those connections use suddenly can't refresh silently anymore because they're being blocked by a policy requirement that demands human interaction, an MFA prompt or a Terms of Use acceptance screen that a background service account can never complete.
The result? Your flow runs fail. Connections break. People picker controls stop working in the Power Automate designer. Flow templates that used to provision with one click now throw cryptic AADSTS50076 authentication errors. And if your organization just enabled the "remember multifactor authentication for trusted devices" setting? That one quietly shortens your connection token lifetime to 14 days, meaning every connection you have will start expiring on a rolling two-week cycle, even ones that were previously refreshing automatically for months.
There are also desktop flow-specific issues, slow-running flow problems, and template connection failures that show up in completely different ways. Power Automate troubleshooting isn't a single problem, it's a family of related problems that all stem from the same root causes: authentication mismatches, policy conflicts, and token expiration.
I know this is frustrating, especially when these flows are blocking actual business processes. Let's get them fixed. Browse all Microsoft fix guides →
The Quick Fix, Try This First
Before you go deep on Power Automate troubleshooting, there's one fix that resolves a majority of broken-flow cases, and it takes about two minutes. The root cause in most situations is a broken or expired connection, not the flow logic itself. Here's exactly what to do.
Open your browser and go to make.powerautomate.com. Sign in, and this part matters, sign in using the same network and authentication method that your Conditional Access policies require. If your organization enforces MFA for SharePoint, complete the MFA challenge before you touch anything in Power Automate. If you're normally on VPN when you work, connect to VPN first. The authentication context you're in when you fix connections is what Power Automate captures for future token refreshes.
Once you're signed in, go to Data → Connections in the left navigation panel. Look for any connections showing a warning icon or a red status indicator. Click on one of the broken connections. You'll typically see an error banner that says something like "This connection is not authenticated" or the full AADSTS50076 message about MFA being required.
Don't delete the connection. Instead, click the three-dot menu (⋯) next to the connection and choose Repair connection or, if that option isn't available, click into the connection and choose Edit then re-authenticate. Walk through the sign-in flow completely, including any MFA challenges. Do this for every connection showing an error.
After repairing all flagged connections, go back to My Flows, find a flow that was failing, and manually trigger a test run. In a large majority of cases, this resolves the issue immediately.
Good Power Automate troubleshooting starts with getting a clear picture of exactly what's broken. You can't fix what you haven't properly diagnosed. Start at make.powerautomate.com → Data → Connections.
Every connection in your environment will show one of three statuses: a green checkmark (connected), a yellow warning triangle (connected but degraded, maybe a permission issue), or a red X (broken, authentication has failed entirely). Write down every connection that isn't green, and note which service it connects to: SharePoint, Exchange Online, Teams, OneDrive, SQL, whatever.
Now go to your failing flow. Click on the failed run in My Flows → [Flow Name] → Run History. Expand the failed action, the one with the red X. The error detail will tell you the specific service that rejected the token. Look for phrases like "access token has expired" or the AADSTS50076 code, which specifically means multi-factor authentication was required but not satisfied by the current token.
Cross-reference this with which Conditional Access policies your Entra ID administrator has active. You can ask your admin to check the Entra ID Sign-in logs at portal.azure.com → Microsoft Entra ID → Monitoring → Sign-in logs and filter for your service account or flow connection owner's UPN. Failed sign-ins caused by Conditional Access will show up here with a clear policy name.
If you see the connection error in the run history but the connection looks fine in the Connections panel, that usually means the policy changed after the connection was created and the token hasn't tried to refresh yet. The connection looks healthy until the next token refresh attempt, then it fails silently during a flow run, which is why the problem seems random.
Once you've matched broken connections to the services and policies involved, you have a clear repair path. If the broken services are SharePoint and Exchange Online, the fix is in how your Conditional Access policy is scoped, which is exactly what Step 2 covers.
The AADSTS50076 error is the single most common error code in Power Automate troubleshooting. When you see it, it means one thing: the token Power Automate is using to connect to a service doesn't carry an MFA authentication claim, but the Conditional Access policy protecting that service requires one.
You'll see this error in two places. First, in the flow run history when a specific action fails. Second, on the Connections page in Power Automate, where an affected connection shows an inline error message. The full text usually reads something like: "Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access [service name]."
Here's the fix sequence. First, sign out of Power Automate completely. Then sign back in, but this time, consciously complete the full MFA challenge. Don't use a trusted device cookie to skip it. You need a fresh token with a live MFA claim.
After signing in with MFA, immediately go to Data → Connections and repair every connection to the services listed in your failing flows. For SharePoint connections, click the three-dot menu → Repair connection → sign in again through the SharePoint OAuth prompt. You may be prompted for MFA again during this step, complete it. Same process for Exchange Online, Teams, and any other flagged connections.
If the connection repair option isn't visible, delete the connection entirely (make a note of the flow that uses it first) and recreate it from scratch. In the Connections panel, click + New connection, find the connector type, and authenticate fresh.
After repairing, run a manual test of the affected flow. The AADSTS50076 error should be gone. If it returns within days, check whether the "remember multifactor authentication" feature is enabled in your Entra ID tenant, that's Step 4's territory and requires admin-level attention.
This is the fix your IT admin needs to be part of, and it's the single most impactful thing you can do to prevent ongoing Power Automate authentication failures at an organizational level. The problem comes down to how Conditional Access policies are scoped.
When IT targets individual applications in a Conditional Access policy, say, they apply an MFA requirement specifically to "SharePoint Online", they create a mismatch. Power Automate, when embedded in SharePoint or Teams, authenticates against its own application ID first, then tries to connect to SharePoint using a separate token. If the MFA requirement exists for SharePoint but not for the Power Automate application itself, the token Power Automate holds doesn't carry the MFA claim that SharePoint's policy demands. The result is a cascade of AADSTS50076 failures across every flow that touches SharePoint.
The fix is to have your Entra ID administrator log in to portal.azure.com → Microsoft Entra ID → Security → Conditional Access and modify the existing policy. Instead of targeting individual applications like SharePoint or Exchange Online, the policy should target either Office 365 (the app suite) or All cloud apps. This way, when a user authenticates into Power Automate, they satisfy the same MFA requirement that SharePoint will check, because both are covered by the same policy with matching requirements.
To make this change in the Azure portal: open the policy → click Cloud apps or actions → change the selection from specific apps to Office 365 → save the policy. The change takes effect within a few minutes for new sign-ins.
After the policy update, have affected users sign out and sign back into Power Automate (completing MFA during that sign-in), then repair their connections. Going forward, the token Power Automate holds will satisfy the SharePoint policy requirements without triggering authentication failures.
If targeting All cloud apps isn't feasible in your environment due to other security requirements, at minimum ensure that every Conditional Access requirement, device compliance, MFA, network location, is identical across every app that Power Automate talks to. Any mismatch will produce failures.
This one catches organizations off guard more than any other Power Automate issue. Your legal or compliance team adds a Terms of Use policy in Entra ID, users have to click "accept" before accessing certain services. Completely reasonable for human users. Completely incompatible with automated Power Automate flows and their background connection refresh processes.
Here's why: Power Automate connections refresh their authentication tokens silently, in the background, with no user session involved. When your Conditional Access policy includes a Terms of Use grant control, the system requires an interactive UI step, the "Accept" button, before granting access. A background token refresh process has no way to display that UI or click that button. The connection refresh silently fails, the connection breaks, and your flows stop running.
You'll notice this problem because flows that were running fine start failing, not immediately when the Terms of Use policy is enabled, but gradually as existing tokens expire and refresh attempts begin failing. The error messages won't explicitly mention Terms of Use, which makes it hard to diagnose without knowing to look for it.
The fix requires admin access to Conditional Access. Go to portal.azure.com → Microsoft Entra ID → Security → Conditional Access → [Your Terms of Use Policy]. In the policy's Users or workload identities settings, add an exclusion for service accounts and any dedicated connection owner accounts that Power Automate flows run under.
Specifically: click Exclude → Users and groups → add the UPNs of your service accounts or dedicated flow connection owners. Save the policy. Those accounts can now refresh tokens without hitting the Terms of Use gate.
After the exclusion is in place, go back to Power Automate and repair the broken connections using those service accounts. The connections should stay healthy going forward as long as those accounts remain excluded from Terms of Use Conditional Access policies.
Make sure these service accounts are documented and monitored. They're a compliance exception and your security team should know they exist.
If your Power Automate connections keep breaking on a 14-day cycle, you fix them, everything works for two weeks, then they fail again, this setting is almost certainly the culprit. The "remember multifactor authentication for trusted devices" feature in Microsoft Entra ID sounds helpful for end users, but it creates a serious problem for Power Automate.
When this setting is active, it modifies the underlying token lifetime policy in Entra ID. Instead of connections being able to hold long-lived refresh tokens (which can last months under normal conditions), the policy forces all tokens to expire within the interval you configured for "remember MFA", often 14 days. Every 14 days, every connection Power Automate holds needs to be re-authenticated. Since that re-authentication requires an interactive session (to satisfy the MFA requirement), the background token refresh fails and connections break.
To check if this setting is active, your Entra ID administrator should go to portal.azure.com → Microsoft Entra ID → Users → All users → Multi-Factor Authentication → then switch to the service settings tab. Look for "Allow users to remember multi-factor authentication on devices they trust", if it's checked with a day value set, that's your problem.
The recommended fix from Microsoft is to disable this setting entirely. Uncheck the option and save. This reverts to standard token lifetime behavior, where connections can use long-lived refresh tokens that don't expire on a short cycle.
Your admin may push back on this because the setting reduces MFA friction for end users. The alternative path is to use Entra ID's Continuous Access Evaluation and proper token lifetime policies instead, which give you fine-grained control without the 14-day connection expiry side effect. But disabling "remember MFA for trusted devices" is the most direct fix for the Power Automate connection cycling problem.
After disabling the setting, repair all broken connections once more using the steps in the Quick Fix section. Going forward, connections should hold their authentication for the standard extended token lifetime.
Advanced Troubleshooting
When the standard fixes don't resolve things, or when you're dealing with desktop flows, enterprise-scale environments, or domain-joined machines, here's where Power Automate troubleshooting gets more involved.
Desktop Flow Errors on Attended and Unattended Machines
Desktop flows have their own failure modes separate from cloud flow authentication issues. If you're seeing an error code when running an attended or unattended desktop flow, the first place to check is the machine status. Open Power Automate for Desktop → Settings → Machine and confirm the machine is registered and showing as Online in the Power Automate portal under Monitor → Machines.
For unattended desktop flows specifically, the Windows account running the flow needs to be able to sign in silently. If that account is subject to Conditional Access policies that require MFA or device compliance checks, unattended runs will fail because there's no user present to complete the challenge. The fix here is the same principle as service account exclusions, the account running unattended desktop flows should be excluded from interactive Conditional Access grant controls, or you should use a dedicated service account configured for non-interactive sign-in.
If you see the message "Power Automate needs an update" when opening Power Automate for Desktop, don't ignore it. Running an outdated desktop agent version is a common cause of UI automation failures. Update through Settings → About → Check for updates or redeploy the MSI package from the Microsoft Download Center. After updating, test your desktop flows with a simple attended run first before scheduling unattended runs.
For UI automation failures with "Failed to get UI element" or "Failed to get window" errors, check whether the target application changed its window title, moved UI elements, or updated its interface. Desktop flow UI selectors are brittle by nature, they match on element attributes that can shift with app updates. Reopen the failing action in Power Automate Desktop's designer and use Repair or re-capture the UI selector against the current state of the application.
Slow-Running Flows
Slow Power Automate flows are usually a throttling problem, not a bug. Microsoft 365 services enforce API call limits, and high-volume flows (processing thousands of items, looping through large SharePoint lists, sending bulk emails) will hit those limits and back off with retry delays. Check the flow run history for "429 Too Many Requests" responses in action outputs, that's your confirmation.
The fix is to add delays between loop iterations using the Delay action, batch your operations where the connector supports it, and avoid using triggers set to run too frequently. For SharePoint polling triggers, a 1-minute interval on a large list will generate more API load than most tenants are licensed for.
People and Email Picker Failures in the Designer
If you're building or editing a flow and the people picker can't find anyone, or Office 365 groups don't appear in search results, this is usually a Conditional Access mismatch between your current sign-in session and the Exchange Online or SharePoint access policies. Sign out of Power Automate, sign back in meeting all Conditional Access requirements (MFA completed, on the correct network), and the people picker will start returning results correctly.
Prevention & Best Practices
Once you've fixed your Power Automate issues, the goal is to make sure you're not back here in two weeks doing it all again. Most recurring Power Automate authentication failures are entirely preventable with the right upfront configuration.
The biggest preventive step is coordination between your IT security team and your Power Automate flow owners before any Conditional Access policy changes go live. I can't overstate how often I see this: IT rolls out a new MFA or Terms of Use policy on a Tuesday and by Wednesday morning a dozen business-critical flows are broken. A 30-minute conversation before the policy change, identifying which flow connections exist and which service accounts they run under, prevents all of that.
When you're setting up new flows, use dedicated service accounts for connection ownership rather than personal user accounts. Personal accounts get moved between departments, change passwords, leave the organization, and hit password expiration policies. A dedicated service account that exists solely to own Power Automate connections is predictable, controllable, and auditable. Make sure that account is properly excluded from Terms of Use Conditional Access policies from day one.
Scope your Conditional Access policies using the Office 365 app target rather than individual application targeting whenever Power Automate is in your environment. This is the configuration Microsoft recommends specifically to avoid the cross-application token mismatch problem that causes most AADSTS50076 errors.
Set up flow run failure alerts. Go to any critical flow → Edit → Settings → Run after, you can configure email notifications when a flow fails. Better yet, create a monitoring flow that checks your critical flows' run history via the Power Automate Management connector and sends a Teams or email alert when failure rates spike. Catching a broken connection on day one is infinitely easier than troubleshooting 500 failed runs three weeks later.
Document your connection ownership. Keep a simple spreadsheet or SharePoint list that maps each critical flow to its connection owner account, the services it connects to, and the last time connections were verified. When something breaks, that document tells you exactly where to start.
- Target Office 365 (not individual apps) in Conditional Access policies to eliminate token mismatch errors
- Exclude dedicated service accounts from Terms of Use Conditional Access grant controls
- Disable "remember MFA for trusted devices" in Entra ID to prevent 14-day connection expiry cycles
- Set up failure notification emails on every business-critical flow so you catch broken connections within hours, not weeks
Frequently Asked Questions
Why do my Power Automate flows keep failing every two weeks?
This is almost always the "remember multifactor authentication for trusted devices" setting in Microsoft Entra ID. When that feature is enabled, it shortens the token lifetime to match the configured "remember MFA" interval, often 14 days. Every two weeks, Power Automate's connection tokens expire, the silent background refresh fails because it can't complete the interactive MFA challenge, and connections break. Have your Entra ID admin disable that setting in the MFA service settings tab. Once disabled, connections will use standard extended token lifetimes and you'll stop seeing this two-week pattern.
What does the AADSTS50076 error mean in Power Automate and how do I fix it?
The AADSTS50076 error means the authentication token Power Automate is using to access a service doesn't include a multi-factor authentication claim, but the Conditional Access policy protecting that service requires one. To fix it: sign out of Power Automate, sign back in and explicitly complete the MFA challenge, don't skip it with a trusted device cookie, and then repair the broken connection from the Data → Connections page. Repairing the connection while you have an active MFA-satisfied session captures a token that carries the required MFA claim.
My flow was working fine and then broke without me changing anything, why?
In almost every case, something changed in your IT environment even if your flow didn't. The most common triggers are: a new or modified Conditional Access policy, a Terms of Use policy being added, a service account password change or expiration, or the "remember MFA" setting being enabled. Ask your Entra ID administrator to check the Sign-in logs in the Azure portal for your connection owner's account, failed Conditional Access evaluations will be logged there with the exact policy name. That'll tell you exactly what changed.
People and groups aren't showing up when I search in the Power Automate flow designer, how do I fix this?
This happens when your current Power Automate sign-in session doesn't satisfy the Conditional Access policies protecting Exchange Online or SharePoint, the services that back the people picker. The people and email picker controls silently fail to query those services when there's a policy mismatch. Sign out of Power Automate completely, reconnect to your corporate VPN or corporate network if required, sign back in and complete any MFA prompt, and then reload the flow designer. The people picker should return full results including Office 365 groups.
Why do my Power Automate 1-click templates fail to set up connections automatically?
Template-based automatic connection creation fails when your sign-in context at the time you use the template doesn't match the Conditional Access requirements of the services that template connects to. Power Automate tries to create connections automatically on your behalf, but if the policy requires MFA and your session doesn't carry that claim, the automatic provisioning is blocked. The fix: before using any template, sign in to make.powerautomate.com meeting all Conditional Access requirements for your environment (MFA complete, correct network, compliant device). Then create the template, the automatic connection creation will succeed.
How do I stop Power Automate desktop flows from failing on unattended runs?
Unattended desktop flow failures most often come down to one of three things: the Windows account running the flow being blocked by an interactive Conditional Access requirement (which needs a service account exclusion in Entra ID), the Power Automate Desktop machine agent being offline or outdated (check the machine status in Monitor → Machines and update the agent), or UI selectors becoming outdated after a target application update (re-capture selectors in the desktop flow designer). Check those three areas in order, machine online status, agent version, then UI selector validity, and you'll find the cause quickly.