Downloading PBIX After Deploying to Lower Stage Results in Changes to Data Model

[m-colbert]

While setting up deployment pipelines, we deployed from our production stage workspace back to an empty Test stage workspace. I then downloaded the report deployed to the Test stage and opened in Power BI Desktop.

I received a message stating "There are pending changes in your queries that haven't been applied" with the option to Apply Changes or Discard Changes.

If I select Apply Changes, the entire data model and all queries are deleted from the report!!!

If I select Discard Changes, a subsequent dialog appears asking to confirm discarding changes and shows every query as having changed. If I then select Discard, the data model appears to be in tact.

This is not just one report, but every report that was deployed from the production to test stage.

Being curious by nature, I took the test and produciton copies of the pbix and unzipped them into folders to look at the differences. Note, the test copy was unzipped using the as downloaded test version, before selecting Apply or Discard, as to not change the deployed format.

I found that in the Test copy, the [Content Types].xml file in the root folder has an additional type defined inthe XML:

<Override PartName="/DataMashup" ContentType="" />

that does not exist in the production copy. 
And an additional file DataMashup in the root folder of the test copy that does not exist in the production copy folders. This file is binary but appears to have all the M code.

It appears that deploying backwards from produciton to the test stage seems to have changed the underlying structure of the PBIX. This seems very odd and is concerning that this may produce the exact same results.

Is this expected, should these files be considered valid to work with? This behavior seems very odd.

Any one else experience this or have an explaination?

Thanks

[m-colbert · Accepted solution]

@Poojara_D12 

Thanks for the reply.

This confirms my suspicions on the change in format. What I have done in the mean time was take the production version and the test deployed version saved them both as PBIP and then compare the individual files in the SemanticModel folder. This confirmed that the tmdl files with the M code were identical with the exception of the workspace and dataflow ids for queries based on dataflows. These values being updated by the auto-binding during deployment, which is expected.  

Therefore, selecting Discard Changes does leave a good file to work with and would expect no differences once refreshed.

As you stated, an alternative would be to download the production version, make the changes to bind to similar data source in similar stages of other pipelines and then publish to test before deploying to production. This still preserves the item pairing. 

Starting over without deploying backwards would require rebuilding the production workspace, app, dataset permissions, etc. since the items would not be paired. That would be quite a bit of work that I don't see as necessary at this time.

Really appreciate your details on the deployment process behavior.

Thanks

[v-echaithra]

Hi @m-colbert ,

As we haven’t heard back from you, so just following up to our previous message. I'd like to confirm if you've successfully resolved this issue or if you need further help.

If yes, you are welcome to share your workaround and mark it as a solution so that other users can benefit as well. If you find a reply particularly helpful to you, you can also mark it as a solution.
If you still have any questions or need more support, please feel free to let us know. We are more than happy to continue to help you.

Thank you for your patience and look forward to hearing from you.
Best Regards,
Chaithra E.

[Poojara_D12]

Hi @m-colbert 

What you're experiencing—where deploying a PBIX report backward from Production to Test using deployment pipelines causes Power BI Desktop to prompt that "There are pending changes in your queries that haven't been applied" and risks deleting the entire data model—is a known quirk in how Power BI packages and reconstructs PBIX files in the service. Specifically, when Power BI Service republishes a report through deployment pipelines (especially from a higher to a lower stage), it doesn't always preserve the internal Power Query state as it was originally authored in Desktop. Instead, it reconstructs the PBIX with a new DataMashup binary part, which contains re-serialized M code and often lacks full metadata to safely round-trip back into Desktop without confusion.

The presence of the DataMashup file and the <Override PartName="/DataMashup" ContentType="" /> line in the [Content_Types].xml confirms that Power BI has repackaged the report with this internal representation. When you open the file in Desktop, it detects inconsistencies between the current M queries and the model—hence the "pending changes" warning. Selecting "Apply Changes" tells Power BI to refresh and regenerate the model from the raw M queries—which, in this scenario, are likely not fully intact or correctly aligned—causing the data model to be dropped. Choosing "Discard Changes" is safer, as it loads the model as-is, without re-triggering a query evaluation.

This behavior is problematic for version control or automated deployments where fidelity between stages is critical. Unfortunately, it's a known limitation with how Power BI pipelines export and reconstruct semantic models in PBIX format. To avoid this, reports should ideally be versioned and stored as original Desktop-authored PBIX files in source control, and deployments should avoid reverse movement (Prod → Test) unless absolutely necessary. If backward deployment is needed, prefer downloading the PBIX before deployment and storing it directly, rather than re-downloading it after it has gone through the pipeline cycle, as the reconstituted PBIX may not behave the same.