A scheduled refresh that ran for months without issue can start failing overnight—often without any schema change or gateway update. If your data source is a cloud API (SharePoint Online, Salesforce, Dynamics, Google Analytics, etc.), the cause is frequently a credential or authentication policy change outside Power BI itself. This article walks through the mechanics of why refreshes break when cloud API authentication evolves, how to distinguish MFA/SSO-induced failures from unrelated errors, and what steps actually restore refresh stability—even if you lack admin control over the source system.
Why Cloud API Credentials Fail Without Warning
The most common refresh failure with cloud APIs is a credential expiry or a policy shift (e.g., MFA enforcement, token lifetime reduction, or delegated app registration removal). The key gotcha is that Power BI, especially when using OAuth 2.0, stores a refresh token in the service—not in your local browser or desktop—so the dataset refreshes out-of-band from your login session. This means:
- Even if you can access the API interactively, scheduled refresh can still fail if the refresh token is revoked, expired, or requires re-consent.
- Multi-factor authentication (MFA) or conditional access policies may not break immediate manual refresh (from Desktop or Service) but will kill scheduled refresh, which has no way to prompt for a new second factor.
- Refresh failures due to expired credentials almost never surface as “credential expired”—instead, you get opaque errors like “invalid_grant”, “token expired”, “failed to authenticate”, or generic 401/403 HTTP errors.
The root cause is that the Power BI Service runs refreshes headlessly, using the last credential you entered via the Service UI. If the API or your organization invalidates that credential (new MFA requirement, changed password, revoked consent, etc.), Power BI will not prompt—it will just fail.
How to Identify an Authentication-Driven Refresh Failure
Not all refresh errors are authentication-related. Before you start resetting credentials or calling admins, isolate the cause. Here’s my process for distinguishing API authentication breakage from other failures:
- Check the error message detail. Look for HTTP 401/403 codes, “invalid_grant”, “invalid_client”, or “token expired”. A 500-series error is likelier to be a source-side outage or throttling; 400-series points to authentication or authorization.
- Compare manual refresh in Desktop to Service refresh. If Desktop works but scheduled refresh fails, the issue is almost always with the Service’s stored credential.
- Review the “Data source credentials” section in the Service. If Power BI prompts you to re-enter or “Edit Credentials” for the data source, the token is likely expired or invalid under new policy.
- Has the organization recently enabled or tightened MFA, SSO, or conditional access? Even if you weren’t notified, these changes can instantly invalidate existing refresh tokens.
- Check the credential type in use. OAuth2, “organizational account”, and service principals behave differently. OAuth2 tokens are most vulnerable to policy or consent change; basic auth can be killed by password expiry; service principals can be restricted by new admin policy.
The most common misdiagnosis is blaming the gateway. With cloud APIs, the gateway is not in play—Power BI Service pulls data directly. If a cloud source fails without a corresponding on-premises gateway error, look to credentials first.
Why MFA and Conditional Access Break Scheduled Refresh—But Not Desktop
This is the central trap: Power BI Service cannot perform interactive authentication. Scheduled refreshes run with whatever credential (token) was last stored through the Service UI. MFA and device compliance checks work for interactive sign-ins, but a non-interactive scheduled process cannot satisfy them.
Take a constructed example with a SharePoint Online data source:
- You publish a dataset using your organizational account. You authenticate via OAuth2, granting consent interactively (possibly with MFA) in the Service.
- IT enables a new conditional access policy: MFA required for all SharePoint access, or device compliance required for all logins.
- Your refresh token, stored in the Power BI Service, is now invalid for scheduled refresh. However, you can still refresh in Desktop, which can prompt for MFA in the browser.
- Scheduled refresh fails with an “invalid_grant” or 403 error, but manual refresh in Desktop works. Re-entering credentials in the Service only works if you satisfy the new policy at that moment—otherwise, you may not be able to store a valid token at all.
The upshot: any policy that requires real-time user interaction or device checks breaks scheduled refresh. There is no workaround that replays an MFA challenge in the Service headless context.
Worked Example: Diagnosing a SharePoint Online Refresh Failure After MFA Rollout
Take a model with a SharePoint Online List as source and scheduled refresh running in the Power BI Service. The organization enables “MFA for all SharePoint access” on a Monday morning.
- Refresh runs at 6am, using a stored refresh token from last week. The new policy is now in effect.
- Refresh fails with:
Data source error: OData: The request failed.
The remote server returned an error: (401) Unauthorized.
Details: "Token expired or invalid_grant".- Manual refresh in Power BI Desktop succeeds (after you complete MFA in the browser pop-up).
- Gateway is not involved (data source is cloud-only).
- Re-entering credentials in the Service triggers a new browser window; you complete MFA, and scheduled refresh resumes working—until the next policy change or token expiry.
What is non-obvious here: the failure is not cached locally, nor is it “fixed” by simply refreshing in Desktop. The Service requires a valid, policy-compliant token, and any policy that cannot be satisfied without user interaction is a permanent risk to scheduled refresh stability. If device compliance is enforced (e.g., only compliant/Azure AD-joined devices can access), you may not be able to store a valid credential from a non-compliant device at all.
How to Restore Scheduled Refresh—And Make It Durable
Here’s the sequence I use to both restore a broken refresh and reduce future risk:
- Re-authenticate in the Service using an account that can satisfy all current policies.
- Go to the dataset’s Settings > Data source credentials.
- Click “Edit Credentials” and re-authenticate, completing MFA if prompted.
- If device compliance is enforced, ensure you are on a compliant device—otherwise, the Service cannot store a usable token.
- Strongly prefer service principals or dedicated “service accounts” exempt from MFA and device compliance for scheduled refresh.
- This often requires Azure AD admin involvement to create and exempt an account or app registration from interactive sign-in policies.
- Document the exemption—future IT policy changes routinely break undocumented service accounts.
- Monitor refresh failures at least daily, not just via email alert but via the Power BI Service UI or API.
- API-based monitoring lets you detect and respond before business users do.
- For critical reports, document the authentication chain and required policies.
- Include which account or app registration owns the refresh credential, and what exemptions are required.
There is no supported way to bypass MFA or device compliance for scheduled refresh except by explicit admin exemption (e.g., conditional access policy exceptions for service accounts or app registrations). Any workaround involving browser automation or credential “replay” is unsupported and likely to break with further policy changes.
Hidden Complication: Consent Revocation and Tenant-Wide App Registration Lockdown
A less-obvious failure mode is tenant-wide consent revocation or lockdown of app registrations. If the organization revokes consent for the Power BI Service to access a cloud API (or disables user/app registrations entirely), scheduled refresh will start failing even if the stored credential is otherwise valid. This frequently happens after a security review or incident response, and is often not communicated to BI developers.
Check the Azure AD Enterprise Applications blade for the relevant app registration and verify permissions and consent are still in place. If you see errors referencing “consent required” or “application not allowed”, no amount of credential resetting will fix the issue until admin consent is restored.
Checklist: What to Do When Cloud API Refresh Fails
- Isolate the error: 401/403/invalid_grant/token errors = authentication; 500-series = source-side or throttling.
- Test manual refresh in Desktop vs. the Service—if Desktop works and Service fails, credentials are at fault.
- Re-authenticate in Service UI, satisfying all new policies interactively.
- Prefer and document service principals or accounts exempted from MFA/device policies for production refreshes.
- Monitor refresh status programmatically (API/powerbi CLI).
- If consent or app registration is revoked, coordinate with Azure AD admins to restore required permissions.
Scheduled refresh against cloud APIs is only as durable as the authentication policy allows. If your organization is moving to MFA or tightening cloud security, expect periodic breakage—and design your refresh accounts and monitoring to catch and recover from it before your business users notice.