Forum Discussion
Power 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.
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
Incremental refresh is a great option for large datasets, but it depends on having a reliable column that identifies new or updated records. Typically, this is a Last Modified or Transaction Date field. If your source doesn't have one, Power BI can't determine which rows need to be refreshed, so it may end up processing more data than expected. If you're using SQL Server, features like Change Tracking or Change Data Capture (CDC) can help identify changes efficiently. Could you share which data source you're connecting to and whether you already have a date or timestamp column available?