Incremental Refresh and PBIP deployment

[dmkblesser]

Hi Community, 

We have implemented a CI/CD deployment pipeline in ADO using REST API to deploy PBIP and it will trigger the Fabric pipeline to move reports/semantic models between dev - uat -prd stages. We are also adopting the `thin report` concept which we split our semantic models and the report files. 

It has been working well so far. However, we are going to develop a new semantic model which we will use incremental refresh on a few of the fact tables in that model. I have been working with semantic models with incremental refresh but never been working with incremental refresh + PBIP deployment. 

My question is, when you set up the semantic model with the incremental refresh rules, nothing changes in the local file. It only creates those partitions after the first refresh in Power BI service. That means, when I push my semantic model to ADO, there is no partitions generated. When it gets refreshed in the service, the partitions get generated. Now if I need to update my semantic model say adding a new measure, the semantic model file in my repo does not contain all the newly created partitions. Would that misalignment break my model? The paritions will be overwritten and I have to re-run the full refresh again? 

Has anyone run into the same use case? Like to hear more from the community and see how you overcome this. I'm also testing this scenario on my end and will post my findings. 

[dmkblesser]

As @Poojara_D12 mentioned and I've tested, the refresh policies and existing partitions retained. 

[Poojara_D12 · Accepted solution]

Hi @dmkblesser 

You're raising a very relevant and practical concern that often comes up when combining PBIP-based CI/CD pipelines with incremental refresh in Power BI semantic models. When you configure incremental refresh in Power BI Desktop and export the semantic model as PBIP, the model definition includes the refresh policy rules but does not include the actual partition definitions—those are created only after the first refresh occurs in the Power BI Service. This means that your PBIP files in source control (e.g., in Azure DevOps) remain agnostic of the actual partitions, which are dynamically generated based on the policy during the first refresh after deployment.

When you later make changes to the PBIP model (such as adding a new measure or updating metadata) and redeploy it through your pipeline, the underlying partition structures in the Power BI Service are not automatically overwritten—they are preserved as long as you are not modifying the incremental refresh policy or deleting tables. Microsoft has designed this behavior to allow developers to continue evolving the model without triggering a full refresh or breaking existing partitions. However, certain changes (like removing and re-adding a table with an incremental refresh policy) can lead to partition resets, causing the model to require a full refresh again.

So, in your scenario, as long as your pipeline deployment logic does not delete and recreate the semantic model or refresh policies, and you are only adding measures or making non-disruptive changes, the service should retain existing partitions and incremental refresh behavior will continue as expected. As a best practice, always test updates in a lower environment and monitor refresh behavior closely after deployment. The community often recommends not forcing a full deployment of the entire PBIP structure if the changes are minor—incremental or partial model updates can help minimize the risk of breaking partition configurations.

[lbendlin]

Also worth noting that you can use Fabric artifacts now to refresh semantic models down to the individual partition, much like you can do via the REST API or XMLA clients.

[dmkblesser]

I remember one speaker in the FabCon talked about the development problem vs organziational problem and this is actually an example of that. I know with tools like notebook, semantic link that we can make a lot of things happen but we cannot just use them yet until the organization establishes auditing/governance framework or even just a pattern around them. 😔