Forum Discussion
Unexpected Report Overwrite in Deployment Pipeline After Publishing SM Directly to Prod
I found a weird issue in Power BI Deployment Pipelines where publishing a semantic model directly into the Production workspace caused an "unrelated" report to be overwritten.
Environment Setup
- Using Deployment Pipelines with Dev → Test → Prod workspaces
- Reports: Report1 and Report2
- Dataset: SM_DataLake
- Typically, I deploy changes through the pipeline.
- The only item I never push through the pipeline is the SM_DataLake report type.
What Normally Happens
- All artifacts except the SM_DataLake report are deployed through the pipeline.
- Semantic model refresh is required at each stage.
What Happened
Last week I needed to urgently update the SM_DataLake semantic model, so I published it directly into the Prod workspace instead of going through the pipeline.
After publishing:
- Report2 report remained unchanged
- The updated semantic model reflected correct data
- But Report1 report was overwritten — its content was replaced with the SM_DataLake report
- No new “SM_DataLake” report was created in the Prod workspace
- Essentially: Power BI replaced the Report1 report with the SM_DataLake report without user input
Has anyone encountered this? I know it's not great to skip the pipeline, but I wouldn't expect this kind of behaviour to happen.
Hey NovaG ,
What you’re seeing is actually a known artifact ID collision behavior in Power BI Deployment Pipelines when you publish directly to a workspace, bypassing the pipeline. Here’s what’s happening in plain terms:
Why It Happened
- Power BI identifies reports and datasets internally by their object IDs, not just their names.
- When you publish a semantic model (SM_DataLake) directly to Prod, Power BI checks the workspace for an existing object with the same internal ID or target slot.
- Since Report1 was occupying the “slot” that the SM_DataLake model used internally, Power BI overwrote Report1 instead of creating a new report.
- This typically doesn’t happen when deploying via the pipeline because the pipeline handles object mapping and ensures unique IDs across environments.
In other words: skipping the pipeline bypassed the safeguards that normally prevent ID collisions between reports and datasets.
Best Practices / How to Avoid
- Always use the Deployment Pipeline for updates, even for urgent fixes. The pipeline preserves artifact relationships and prevents accidental overwrites.
- Never publish a semantic model directly to Prod if reports already exist in that workspace. If needed, use “Save As” or rename the artifact before publishing.
- Verify internal object names/IDs if you must publish manually. You can use tools like Tabular Editor or the Power BI REST API to inspect model IDs.
- If a direct publish is unavoidable, consider publishing to a temporary workspace first to ensure nothing is overwritten, then use the pipeline to promote changes.
Power BI relies on internal IDs, not report names, when managing objects. Bypassing the pipeline removes the safety net, which is why Report1 was replaced with the semantic model. In practice, direct Prod publishing of semantic models is risky and should be avoided.
If this explanation helped, please mark it as the solution so others can find it easily.
If it helped, a quick Kudos is always appreciated it highlights useful answers for the community.
Thanks for being part of the discussion!
3 Replies
- MohdZaid_
Super User
Hey NovaG ,
What you’re seeing is actually a known artifact ID collision behavior in Power BI Deployment Pipelines when you publish directly to a workspace, bypassing the pipeline. Here’s what’s happening in plain terms:
Why It Happened
- Power BI identifies reports and datasets internally by their object IDs, not just their names.
- When you publish a semantic model (SM_DataLake) directly to Prod, Power BI checks the workspace for an existing object with the same internal ID or target slot.
- Since Report1 was occupying the “slot” that the SM_DataLake model used internally, Power BI overwrote Report1 instead of creating a new report.
- This typically doesn’t happen when deploying via the pipeline because the pipeline handles object mapping and ensures unique IDs across environments.
In other words: skipping the pipeline bypassed the safeguards that normally prevent ID collisions between reports and datasets.
Best Practices / How to Avoid
- Always use the Deployment Pipeline for updates, even for urgent fixes. The pipeline preserves artifact relationships and prevents accidental overwrites.
- Never publish a semantic model directly to Prod if reports already exist in that workspace. If needed, use “Save As” or rename the artifact before publishing.
- Verify internal object names/IDs if you must publish manually. You can use tools like Tabular Editor or the Power BI REST API to inspect model IDs.
- If a direct publish is unavoidable, consider publishing to a temporary workspace first to ensure nothing is overwritten, then use the pipeline to promote changes.
Power BI relies on internal IDs, not report names, when managing objects. Bypassing the pipeline removes the safety net, which is why Report1 was replaced with the semantic model. In practice, direct Prod publishing of semantic models is risky and should be avoided.
If this explanation helped, please mark it as the solution so others can find it easily.
If it helped, a quick Kudos is always appreciated it highlights useful answers for the community.
Thanks for being part of the discussion!
v-achippaCommunity Support
Hi NovaG,
Thank you for reaching out to Microsoft Fabric Community.
Thank you MohdZaid_ for the prompt response.
As we haven’t heard back from you, we wanted to kindly follow up to check if the solution provided by the user for the issue worked? or let us know if you need any further assistance.
Thanks and regards,
Anjan Kumar Chippa