Forum Discussion
Advocate IPower BI Incremental Load HELP
Yes, publishing your Desktop PBIX with Replace will overwrite the dataset in the Service with the model that only has data through May 31. The historical partitions built up by the daily refreshes (June 1 to June 27) will be discarded. After that, the next scheduled refresh will only bring in the last 4 days based on your incremental policy, so you would have a gap roughly from June 1 to around June 23.
The standard approach once incremental refresh is running is to stop republishing the full PBIX from Desktop. Instead, you push only the metadata changes (new pages, visuals, new measures) to the published dataset using the XMLA endpoint, typically with Tabular Editor or ALM Toolkit. That preserves all the data partitions already in the Service. This path requires PPU or Premium capacity for XMLA write access.
If you are on Pro and cannot use XMLA, the practical workaround is to widen the incremental refresh policy window so a republish can rebuild the full range from the source, assuming the source still holds the historical rows.
If this helped, a thumbs up and accepting it as the solution would be appreciated.
Best regards,
Shai Karmani- The danger is that replacing the full PBIX can replace the semantic model in the Service, including the partitions that were built by incremental refresh.The standard pattern in real projects is to separate the semantic model from the report:
- one PBIX / semantic model for the dataset, incremental refresh, relationships, measures
- separate thin report PBIX files connected live to that semantic modelThen you can update pages and visuals without republishing the semantic model and without risking the historical partitions.If you need to change measures or model metadata, that is different: measures live in the semantic model. In Premium / PPU / Fabric capacity, you can use XMLA-based tools such as Tabular Editor or ALM Toolkit to deploy only metadata changes and preserve existing partitions.If you are on Pro only, the safer workaround is to make sure your incremental refresh policy can rebuild the needed history from the source, because republishing the full PBIX can reset the Service model.So the best practice is:- avoid republishing the full PBIX once incremental refresh is running- use thin reports for visual/page changes- use XMLA/ALM tools for model or measure changes where available- keep enough historical data in the source so the model can be rebuilt if needed🔍Parchitect
Solutions Architect · Microsoft Fabric Specialist💡Helpful? Kudos are appreciated.
✔️Solved? Mark as Solution so others can find it faster.
Super UserHi mustafa_data ,
I hope you are doing well today ☺️✨
So deploying the local .pbix file which contains a data snapshot limited to May 31st via the Replace option will overwrite the existing semantic model residing in the Power BI Service
This action will purge the incremental partitions that were built by daily scheduled refreshes from June 1st through June 27th following the overwrite and the next scheduled refresh will execute strictly according to your 4 day incremental policy retrieving only the most recent window (approximately June 23rd to 27th)
Note: This creates a permanent data gap for the period spanning June 1st to June 23rd unless immediate manual remediation is performed.
So here is also recommended approach (Workaround) for PowerBI Pro license:
- Temporarily expand the Store rows from the past window within your refresh policy to encompass the complete historical period (e.g., from January 2025 to the current date)
- Deploy the updated .pbix file to the Service via the replace option
- Immediately trigger a Full Refresh on the published dataset to materialize all historical data from the source system
- Once the refresh completes successfully revert the incremental policy to your preferred 4day retention window
mustafa_dataHi Ahmed,
Thank you.
I currently have a 4-day incremental refresh policy configured in Power BI Desktop. Suppose I temporarily change it to 30 days, then republish the report and trigger a refresh in the Power BI Service. The service correctly loads the last 30 days of data, which is expected.
Now I want to switch the policy back to 4 days. To do that, I open the same Power BI Desktop file (which still contains data only up to 31 May), change the policy back to 4 days, and republish the report.
My understanding is that this republishes the model from Power BI Desktop, which contains data only up to 31 May, and overwrites the existing model in the Power BI Service.
If that's the case, what is the benefit of changing the incremental refresh policy? Doesn't republishing the report overwrite the existing model and require the service to rebuild it again?
Could you please clarify how this is supposed to work?