Forum Discussion
Report not overwriting in workspace, creates a duplicate instead
Check for trailing spaces or other invisible characters in the pbix name.
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*
-
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.
-
-
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.
-
-
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.
-
-
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.
-
Super UserHi 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.