Power BI Data Source Credentials Error

A Power BI data source credentials error is one of the most common reasons a report stops refreshing, and it often creates confusion because the dashboard itself may still open and look normal. The visuals are there. The model is published. The report worked before. But now the service says the data source credentials are missing, invalid, or cannot be updated.

That is why this issue matters so much.

For many teams, this error means:

• scheduled refresh stops
• dashboards go stale
• finance or operations reports stop updating
• users lose trust in the numbers
• analysts waste time checking visuals when the real problem is authentication underneath

The good news is that this error usually comes from a small group of causes. In most cases, the problem is one of these:

• expired or changed credentials
• wrong authentication method
• service-side credentials not matching Desktop behavior
• gateway issues
• privacy or source-combination conflicts
• unsupported source patterns
• tenant or organizational sign-in mismatches
• local cached credentials hiding the real issue until publish time

This guide explains what the Power BI data source credentials error really means, why it happens, how to troubleshoot it in the right order, and how to reduce the chances of it happening again.

Overview

A data source credentials error means Power BI cannot authenticate to a data source the way the semantic model expects.

That might mean:

• the saved credentials are missing
• the password or sign-in has expired
• the authentication method is wrong
• the source requires a different kind of credential than the one configured
• the source works locally in Desktop but not from the service
• the service cannot reach the source through the expected gateway path
• the source is configured differently in the service than it was in Desktop

In simple terms, Power BI is saying: “I know where the data should come from, but I cannot successfully sign in or validate access to it the way this model requires.”

That is the core idea.

What this error actually means

A credentials error is not always just “the password is wrong.”

That is important to understand.

Sometimes the error really is a bad password or expired sign-in. But sometimes it is a broader connection-authentication problem such as:

• the service is using the wrong credential type
• the gateway is misconfigured
• the source mapping does not match
• the account lacks permission
• the source is in a different tenant than the OAuth setup expects
• privacy or query-combination rules block the refresh
• the source path used in Desktop is not valid for the service

So the error message is often the symptom, not the full root cause.

That is why good troubleshooting needs to look at the whole refresh path.

The most common credential error messages

Different Power BI setups surface this problem in slightly different ways, but common messages often include wording such as:

• data source credentials are missing or invalid
• the credentials provided for the data source are invalid
• unable to update this data source’s credentials
• the source credentials are missing
• refresh failed because the data source credentials are invalid

Even though the wording varies, the practical troubleshooting path is often similar.

Why credentials errors happen so often

Credentials errors are common because Power BI Desktop and the Power BI service are not the same environment.

In Desktop:

• you may already be signed in
• your machine may have direct access to the source
• your credentials may be cached
• your local network or VPN may make the source reachable
• privacy settings may behave differently
• a gateway is not needed for local testing

In the service:

• the semantic model needs service-side credentials
• the data source must be supported for refresh
• the source may require a gateway
• the authentication method must be configured correctly
• privacy and tenant rules can affect access
• local assumptions no longer help

That difference is one of the biggest reasons a model refreshes in Desktop but fails with a credentials error after publish.

Start with refresh history and model settings

The first place to begin is the Power BI service, not the visual layer.

A strong first workflow is:

• open the semantic model settings
• review the Data source credentials section
• open refresh history
• identify the exact source involved
• check whether the failure started recently or has always been present

This matters because the timing of the failure often tells you a lot.

If it worked before and stopped suddenly, common causes include:

• password change
• expired token
• source permission change
• gateway issue
• service-side sign-in expired

If it never worked in the service, common causes include:

• wrong auth method
• unsupported source pattern
• missing gateway
• Desktop-only source logic
• source definition mismatch

That difference is important.

The simplest cause: expired or changed sign-in

One of the most common causes is that the sign-in simply needs to be refreshed.

This often happens when:

• an organizational account password changed
• a token expired
• the user’s source permission was updated
• the original sign-in was not fully completed
• the model was republished under a different ownership context

This is especially common with:

• SharePoint Online
• OneDrive
• cloud business systems
• organizational OAuth sign-ins
• sources using Microsoft organizational identity

A practical first fix is to edit credentials in the Power BI service and sign in again with the correct account.

Wrong authentication method

Another common issue is using the wrong authentication method for the source.

A source may require:

• Organizational account
• Basic
• Windows
• OAuth2
• another connector-specific method

If the wrong method is selected, Power BI may show a credentials error even if the username and password are technically valid in some other context.

This is especially common when:

• the source was changed after initial setup
• the model moved between environments
• a user guesses the auth type
• Desktop and Service do not match exactly

So when troubleshooting, do not just re-enter the same details. Confirm that the authentication method itself is correct.

Missing permissions on the source

Sometimes the credentials are valid, but the account does not actually have permission on the source.

This can happen when:

• the account can sign in but cannot access the data
• the database is reachable but the user lacks table or schema permissions
• the folder or file exists but the account cannot open it
• the source requires a different tenant or workspace permission path
• the service account is different from the one used locally

This matters because Power BI may surface that as a credentials-style failure even though the deeper issue is authorization, not authentication.

Tenant and organizational-account mismatches

One particularly important cloud-source pattern is tenant mismatch.

This is especially relevant when using organizational account and OAuth-style access with Microsoft services.

In practice, some service refresh scenarios require:

• the same organizational identity to be used properly
• the service-side sign-in to match the right tenant context
• the source to be accessible under that tenant relationship

If the model connects locally in Desktop with one identity pattern but the service refresh tries another, the result can look like a credentials problem.

That is why cloud identity context matters more than many users expect.

Gateway-related credential errors

A credentials error is not always purely about the credential itself. Sometimes the gateway is involved.

Common gateway-related situations include:

• gateway offline
• gateway source not mapped correctly
• gateway machine missing required connector drivers
• source defined differently in the gateway than in the model
• gateway can reach the server but not with the expected authentication setup
• the service checks credentials through the gateway and the test fails

This is one reason gateway troubleshooting is so important when a credentials error appears after publish.

If the source is on-premises or requires a gateway path, the credentials error may be the front-end symptom of a gateway configuration problem.

Why Desktop can hide the problem

A model can work perfectly in Desktop and still fail in the service because Desktop benefits from your local environment.

Examples:

• you are already signed in locally
• you have direct VPN or local network access
• the local source path exists on your machine
• your cached credentials still work
• the gateway is not needed locally
• the Desktop file is using a source pattern the service cannot refresh

That is why “but it works in Desktop” is useful information, but it does not prove the service is configured correctly.

Privacy settings can also surface as credential issues

Another subtle cause is privacy and source-combination behavior.

This matters when:

• the query combines multiple data sources
• one source is private and another is organizational or public
• the Desktop file was authored with local privacy assumptions
• the service tries to refresh with stricter combination behavior

In these cases, the final symptom can look like a credentials problem even though the deeper issue is how Power Query is allowed to combine sources.

This is especially important if the model uses:

• merges
• appends
• lookup queries from multiple systems
• dataflows or cloud-plus-local combinations

Unsupported refresh patterns

Sometimes the real issue is that the source pattern used in Desktop is not supported for service refresh.

In those cases, users may keep trying to re-enter credentials even though the service cannot use that source path the way the model was built.

Examples of risky patterns include:

• local file paths
• source setups that only make sense from the author’s machine
• unsupported connectors or unsupported scheduled refresh scenarios
• environments that need a gateway but do not have one configured

That is why one troubleshooting step should always be: Can this source pattern actually refresh in the Power BI service?

Cached credentials in Desktop

Sometimes Power BI Desktop itself holds on to cached credentials that confuse the authoring experience.

This matters when:

• a source changed authentication method
• a different account was previously used
• an expired token is still cached
• Desktop appears connected, but the underlying auth state is misleading

In those situations, clearing permissions locally in Desktop can help reset the source connection and make the model setup cleaner before republishing.

This is especially useful when the service and Desktop behavior seem oddly inconsistent.

How to troubleshoot the error in the right order

A structured order saves a lot of time.

Step 1: Identify the exact failing source

Do not assume. Open the semantic model settings and refresh history and confirm:

• which source is failing
• whether one or multiple sources are involved
• whether the failure is immediate or occurs later in the refresh

Step 2: Re-enter credentials in the Power BI service

Open Data source credentials and:

• choose the correct authentication method
• sign in again with the right account
• confirm the privacy level selection if applicable

This solves a large share of cases.

Step 3: Check whether the account actually has access

Verify that the account can really access:

• the file
• the site
• the folder
• the database
• the schema
• the API or application source

Signing in is not enough if the account is not authorized for the needed data.

Step 4: If a gateway is required, verify the gateway path

Check:

• is the gateway online?
• is the gateway updated?
• does the gateway machine have the right drivers?
• does the gateway source definition match the model?
• are the server and database details exactly aligned?

Step 5: Compare Desktop and Service assumptions

Ask: What is working locally that the service may not be able to reproduce?

Examples:

• local file access
• cached sign-in
• VPN-only access
• ignored privacy settings
• unsupported source pattern
• different account context

Step 6: Review privacy and source-combination logic

If the model combines multiple sources, review whether privacy rules or query-combination logic may be blocking service refresh.

Step 7: Check for unsupported refresh scenarios

Make sure the source and refresh pattern are actually supported in the service.

Common real-world examples

Example 1: “Data source credentials are missing or invalid” after password change

Likely cause:

• the organizational sign-in or password changed

Best first move:

• update the credentials in the Power BI service and test refresh again

Example 2: “Unable to update this data source’s credentials”

Likely causes:

• wrong auth method
• source definition mismatch
• tenant mismatch
• gateway issue
• unsupported service path

Best first move:

• verify the exact source, auth method, and whether a gateway is involved

Example 3: Works in Desktop, fails in Service

Likely causes:

• service-side credentials not configured properly
• gateway missing or broken
• privacy mismatch
• Desktop-only access path
• unsupported source scenario

Best first move:

• compare Desktop connection behavior to service requirements line by line

Example 4: Credential error appears only after publishing to another workspace

Likely causes:

• different model owner context
• missing takeover of semantic model settings
• credentials not transferred as expected
• service account mismatch

Best first move:

• confirm who owns the semantic model settings and update the credentials under the correct context

Example 5: Cloud source refresh fails even though account signs in successfully

Likely causes:

• the account can authenticate but lacks source authorization
• tenant context mismatch
• long-running refresh behavior
• privacy or source-combination issue

Best first move:

• verify both source permission and refresh environment, not just the sign-in itself

Common mistakes people make

Re-entering the same credentials repeatedly without checking the auth method

The problem may be the method, not the password.

Assuming the service works the same way as Desktop

It does not. That assumption causes a lot of wasted troubleshooting time.

Ignoring the gateway

If the source depends on gateway infrastructure, credentials cannot be isolated from that environment.

Troubleshooting visuals instead of the data path

A credentials error is usually a pipeline problem, not a report-page problem.

Forgetting privacy settings when combining multiple sources

This is a subtle but common reason service refresh behaves differently.

How to reduce future credentials errors

A few habits make these errors less frequent.

Standardize source configuration

Use consistent source paths and naming across:

• Desktop
• gateway
• service settings

Keep gateway setup healthy

Update the gateway, maintain drivers, and monitor whether the mapped sources still align with the model.

Use stable supported sources where possible

Avoid fragile source paths that only work from one local authoring machine.

Clean up local cached permissions when debugging

If Desktop behavior becomes confusing, reset and reconnect cleanly before publishing again.

Document who owns the semantic model credentials

This matters especially in team environments.

Monitor refresh history regularly

Do not wait for a stakeholder to tell you the dashboard is stale.

FAQ

Why does Power BI say data source credentials are missing or invalid?

Power BI usually shows this error when the service cannot authenticate to the data source because the saved sign-in is expired, incomplete, incorrect, using the wrong authentication method, or blocked by a related gateway or source-configuration issue.

How do I fix data source credentials errors in Power BI?

Start by going to the semantic model settings in the Power BI service, opening Data source credentials, and updating or re-signing the affected source. Then verify the source type, privacy level, gateway setup, and whether the service-side configuration matches what worked in Power BI Desktop.

Can a gateway cause a Power BI credentials error?

Yes. Gateway issues can surface as credentials-related failures when the source mapping is wrong, the gateway is offline, the gateway machine is missing drivers, or the connection details do not match the model.

Why does refresh work in Desktop but fail in the Power BI service?

That usually happens because Desktop uses your local environment and cached access, while the Power BI service needs its own credentials, supported refresh path, privacy behavior, and gateway configuration.

Final thoughts

A Power BI data source credentials error feels simple on the surface, but it often points to a deeper mismatch between the model, the service, the source, and the environment around them.

That is why the best fix is not random trial and error.

Start by identifying the exact source. Re-enter the credentials in the service. Confirm the authentication method. Check actual source permissions. Then look at gateway setup, privacy rules, and whether the service refresh pattern is genuinely supported.

That order solves the problem much faster.

And once you start thinking of credentials errors as part of the full refresh pipeline, not just as sign-in prompts, Power BI becomes much easier to troubleshoot and much easier to keep reliable in real business reporting workflows.