When Power Query says it could not authenticate to SharePoint, first verify the SharePoint URL and connector, then clear the saved permission for that exact data source and sign in again with Organizational account. Do not start by deleting Windows identity folders or disconnecting work accounts.
The same message can describe several failures, so work from the least disruptive check to the most administrative one.
1. Confirm the source URL
For the SharePoint Folder connector, use the site URL, not a copied file-sharing link or the full path to a workbook.
For example:
https://contoso.sharepoint.com/sites/Finance
Open the site in a private browser window and sign in with the account Power Query should use. Confirm that account can reach the site and file.
Browser access is useful evidence, but it does not prove the desktop connector is authorised. Conditional Access can treat browser and desktop clients differently.
2. Clear only the saved Power Query permission
Microsoft documents this route for Excel desktop:
- Open Excel.
- Select Data > Get Data > Data Source Settings.
- Select Global permissions.
- Find the SharePoint source at the relevant URL level.
- Select Clear Permissions.
- Close the dialog and refresh the query.
- Choose Organizational account and sign in with the intended tenant account.
In Power BI Desktop, use File > Options and settings > Data source settings.
Power Query reuses saved credentials for a URL and its subaddresses. Clearing the wrong level can leave the conflicting credential in place. Conversely, Clear All Permissions signs Power Query out of every saved source, so avoid it unless that wider reset is intentional.
3. Check the query's connector and privacy level
Open the query and inspect the first source step.
Check that:
- it uses the intended SharePoint connector;
- the hostname belongs to the correct tenant;
- the site path has not changed;
- the authentication type is supported for that connector;
- privacy-level choices are appropriate when combining sources.
Microsoft's Power Query authentication guide explains that credential selection is stored against connection parameters and can be edited or cleared in Data Source Settings.
4. Separate identity from permission
If fresh sign-in succeeds but the query still fails, ask the site owner to verify access to the site, library and target file with the same account.
Do not assume Site Administrator, Microsoft 365 administrator or browser access grants every data permission. Also check whether the query reaches another file, list or API after the initial SharePoint connection.
For guest and multi-tenant accounts, record the home tenant, resource tenant and account shown in the sign-in prompt. Use a dedicated browser profile to inspect the resource if that helps you avoid choosing the wrong identity, but remember that a browser profile does not control Power Query's saved desktop credentials.
5. Ask the administrator to check policy evidence
If the error affects several users, started after a policy change or occurs only on managed devices, collect:
- the UTC failure time;
- user principal name;
- SharePoint site URL;
- Excel or Power BI version;
- device and network state;
- correlation or request identifiers, if shown;
- the matching Microsoft Entra sign-in log entry.
An authorised Entra administrator can then check Conditional Access, sign-in risk, device compliance and client-app conditions. Do not weaken tenant policy simply to make one refresh succeed.
Avoid destructive cache advice
Deleting OneAuth, IdentityCache or broker-plugin data is not a routine Power Query fix. Those stores affect Microsoft 365 and Windows sign-in more broadly, and Microsoft support guidance should be followed for the exact diagnosed condition.
Likewise, disconnecting an account under Access work or school can remove device management or single sign-on state. Treat it as an administrator-led recovery step, not the opening move.
Prove the repair
After changing the saved permission:
- refresh the query;
- confirm the expected row count and source file;
- close and reopen the workbook;
- refresh again;
- test as the intended ordinary user where relevant.
A successful refresh proves that query worked with that account and policy state at that time. It does not prove every user, gateway or scheduled refresh will work.
For help separating SharePoint access, connector credentials and policy failures, join the SharePoint & Teams Admins Space.