Incremental Refresh and PBIP deployment

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.