Publish Semantic Model causing Connection Break

Hi powerbiexpert22​,

The replies above are pointing in the right direction, but one important detail is that deployment pipelines do not copy semantic-model data source credentials into the target stage.

Microsoft documents that data source credentials are one of the semantic-model properties that are not copied during deployment.

See the deployment pipeline process documentation.

So I would separate two concerns:

release process
→ Dev / Test / Prod deployment pipeline

connection stability
→ stable gateway or shareable cloud connection configured once in Prod

In the Power BI Service, open the semantic model settings and check:

Gateway and cloud connections

Microsoft’s current cloud connection guidance allows a semantic model to map to a shareable cloud connection rather than relying on a personal connection.

For gateway-based sources, I would do the same conceptually:

create/manage the gateway connection centrally
→ map the Prod semantic model to that connection
→ keep the source definition consistent between releases

If the semantic model repeatedly loses its mapping every time you publish, I would also compare whether anything in the source definition is changing between versions:

• server/database
• M parameters
• file/path location
• connector type
• authentication method

If those stay identical, a normal model update should not require rebuilding the whole connection architecture every time.

So my preferred setup would be:

Dev model
→ validate in Test
→ deploy model changes to Prod
→ keep Prod mapped to a stable centrally managed connection

and keep the reports connected to that governed Prod semantic model.

That avoids making credential/gateway repair part of every release.

AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.

Hello powerbiexpert22​,

If publishing/replacing the PBIX causes you to reconfigure credentials and the gateway connection each time, that creates a production risk because there is a period where the semantic model exists but isn't correctly connected to its data source. That would explain why users occasionally report that the report is unavailable or not working as expected.

For a Production environment, I would consider two approaches.

1. Dev → Test → Prod using Deployment Pipelines

Instead of developing the PBIX and publishing it directly over Production, maintain separate Dev, Test and Prod workspaces and promote the content through a deployment pipeline.

For example:

Dev workspace
Test workspace
Prod workspace

The Production environment should keep its own data source configuration, parameters, gateway mappings and credentials wherever possible. Environment-specific connection information can also be managed using parameters/deployment rules rather than manually changing the PBIX before each release.

This also gives you the opportunity to validate refresh, gateway connectivity and reports in Test before promoting the change to Production.

2. Separate the semantic model from the reports

If several reports depend on the same semantic model, I would also consider maintaining one governed Production semantic model and connecting the reports to it using a Power BI semantic model connection.

Instead of repeatedly replacing an entire PBIX containing both the report and model, your architecture becomes something like:

Production Semantic Model
→ Report A
→ Report B
→ Report C

This reduces the number of objects affected when you make changes to the model and is generally easier to manage when multiple reports share the same semantic model.

Power BI supports multiple reports connecting to a common semantic model, which is useful for exactly this type of lifecycle management scenario.

One important point, though: Deployment Pipelines aren't a guarantee that credentials or gateway mappings will never require attention. Data source configuration, parameters and gateway bindings still need to be designed correctly for each environment. I wouldn't rely on repeatedly overwriting the Production PBIX as a way of preserving those settings.

For a critical Production model, my preferred approach would therefore be:

Develop in Dev → validate in Test → deploy to Prod → validate the Production connection/refresh

rather than:

Develop locally → overwrite Production PBIX → repair credentials/gateway

That removes the manual reconfiguration step from the normal release process as much as possible and, more importantly, reduces the risk of users being impacted during deployments.

Microsoft documentation on lifecycle management: https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-implementation-planning-content-lifecycle-management-deploy

Power BI semantic model connections: https://learn.microsoft.com/en-us/power-bi/connect-data/desktop-report-lifecycle-datasets

DISCLAIMER: While I wrote a draft of this answer, I used Copilot to create a longer, more detailed step-by-step description to make it easier to apply.

Yup, what Ibarrau said.

Everytime I overwrite my semantic model in power bi service, I never had any issue with connection breaking or reentering credentials.

When you make edits and republish, did you for example change the source data, or use a different path for source, or edit the path even like changing lowercase to uppercase? That would be the only thing i can thing off for now, that could affect connection configuration.

Hi. A good practice would be creating the connections at the Power Bi Service once and map them to the semantic model. If you have onpremise source, usually that's mandatory for gateway, but if you have cloud sources, it's not mandatory, it's a good practice.

You can go to manage gateway and connections and create one for each source of the semantic model or open the semantic model schedule refresh/configuration at gateway and sources section. You will see the sources listed, create a source for each one and assign it.

That way it will remember to always use that configuration. You can see an example here: https://learn.microsoft.com/en-us/power-bi/connect-data/service-connect-cloud-data-sources#compare-shareable-cloud-connection-to-other-connections

I hope that helps,