Report not overwriting in workspace, creates a duplicate instead

[mp9531943781]

I'm running into a frustrating issue with a report that was originally published in our production workspace. I'm trying to update it by publishing the latest PBIX file, which I downloaded directly from that same workspace. But instead of overwriting the existing report, Power BI creates a duplicate with the same name.

The strange part is that when I publish the same file to my personal workspace, it works exactly as expected. It prompts me to overwrite the existing report and does so without any issues. But in the production workspace, it doesn't prompt at all and just creates a second copy.

The challenge is that I can't delete the original report or dataset before publishing, because both are being used as a source in other workspaces for other reports.

I've already tried using the latest versions of Power BI Desktop from May and June 2025, and I've published both from Desktop and the Service, but the behavior doesn't change.

Is there any way to fix this without deleting the original report and breaking downstream connections? Would appreciate any help or ideas.

[lbendlin · Accepted solution]

Check for trailing spaces or other invisible characters in the pbix name.

[v-priyankata]

Hi @mp9531943781 
@rohit1991 @Poojara_D12 Thanks for the inputs.

Hope everything’s going smoothly on your end. We haven’t heard back from you, so I wanted to check if the issue got sorted  If yes, marking the relevant solution would be awesome for others who might run into the same thing.

[rohit1991 · Accepted solution]

Hi @mp9531943781 ,

*Why It’s Creating a Duplicate*

• Power BI identifies reports by internal IDs, not just by name. If that internal ID doesn’t match, even if the PBIX was downloaded from the same workspace, it will treat the upload as a new report.

• Publishing from Desktop does not support dataset binding, so it can't detect or overwrite existing reports unless the internal metadata matches exactly.

• In personal workspaces, Power BI is more lenient and prompts to overwrite—but in shared or production workspaces, especially with downstream dependencies, it's more cautious.

* What You Can Try*

1. Use Power BI Service to Overwrite: Instead of publishing from Desktop, go to the Power BI Service:

   • Open the existing report in the workspace.

   • Click the “Upload a file” > “Replace report” option.

   • This keeps the same dataset and connections intact and avoids creating a duplicate.

2. Check Report Binding with Power BI REST API (Advanced):

   • If you're familiar with scripting, use the Power BI REST API to rebind the new report to the existing dataset after upload.

3. Avoid Deleting the Original:

   • Since it's used as a source in other workspaces, do not delete the report/dataset. Instead, try the overwrite or rebind approach.

4. Naming Convention as a Last Resort: If overwrite isn't possible, you could:

   • Publish with a different name,

   • Rebind the downstream reports to the new dataset (if possible), and

   • Then retire the old report—but this can be risky and time-consuming.

* Additional Tips*

• Ensure you have sufficient permissions (typically Member or Contributor) to overwrite reports in the workspace.

[Poojara_D12]

Hi @mp9531943781 

You're encountering a common but tricky issue in Power BI where publishing a PBIX file fails to overwrite the existing report and dataset in a workspace, resulting in a duplicate—despite the file originating from that very workspace. This behavior is usually tied to dataset ownership and internal linking mechanics, especially in shared or production environments where the dataset is reused across workspaces. In Power BI, overwriting only works when the PBIX file has the same internal dataset ID and report ID as what's already published, and the user has full rights to both. However, once a dataset is being used as a shared or linked dataset (i.e., thin reports depend on it across other workspaces), Power BI becomes more conservative to avoid accidentally disrupting those dependencies. That’s why you see correct overwrite behavior in your personal workspace—where such links don’t exist—but not in production.

Because you can't delete the existing dataset without breaking downstream reports, your safest option is to decouple the PBIX file into a thin report—i.e., remove the dataset from the PBIX, connect it to the existing dataset in the Service, and publish it. This avoids touching the dataset and only updates the report. To do this, open the PBIX, go to Model View, and delete all tables, then use Get Data > Power BI datasets to connect to the original semantic model in the production workspace. After reconnecting visuals and saving, publish this PBIX—it will overwrite the existing report without duplicating the dataset, assuming the report name matches and you have appropriate permissions.

Alternatively, you could use deployment pipelines if your workspace is part of a Premium or Fabric capacity. Pipelines preserve object IDs and handle report overwrites more predictably, ensuring updates happen without duplicating or affecting linked artifacts.

In short, this behavior arises due to how Power BI treats linked datasets and report ownership across shared environments. Converting your PBIX into a thin report or using deployment pipelines are the best approaches to ensure clean updates without breaking dependencies.

[v-priyankata]

Hi @mp9531943781 
@Deku @lbendlin Thanks for your inputs.

The points shared was helpful to you. If your question has been answered, kindly mark the most relevant reply as the Accepted Solution. This small action can make a big difference for others who are looking for the same solution.

[v-priyankata]

Hi @mp9531943781 

I wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions.

[lbendlin · Accepted solution]

Check for trailing spaces or other invisible characters in the pbix name.

[Deku]

You could run the Update Report Content In Group API to replace the context of the old report with the new one.

Or use git integration. Setup integration and sync the workspace to GitHub or ADO. Overwrite the contents of the old report with the new one. But don't overwrite the 
.platform file. Then push back to the workspace.