Forum Discussion
Advocate IFabric CI/CD Semantic models And Variable Library
Hi All,
I have created a deployment pipeline in Azure DevOps that successfully deploys from my repo into the target workspace.
What I can not seem to get working is the Semantic model and Variable Library.
When I deploy these the semantic model remains pointing at the source workspace and the Variable library defaults back to default.
Has any one managed to get the Models to bind to the correct Lakehouse and set the Varible Library to the correct Environment when deploying using DevOps and Fabric CLI?
Any help is appreciated Thanks!
Hi BalfourBen ,
Both behaviors are expected right now, not a pipeline bug.
Semantic Model pointing to source workspace – The model definition in Git carries the original SQL endpoint connection string and database GUID. fabric-cicd and Fabric CLI don't rebind it automatically. You have to either parameterize it in parameter.yml (a find_replace for the connection string + the DB id) or rebind it post-deploy using the new Bind Semantic Model Connection REST API. Common pattern: deploy everything except the semantic model first, grab the new Lakehouse SQL endpoint id via fab api, inject it into parameter.yml, then deploy the model.
Variable Library reverting to "default" – The active value set is a per-workspace configuration, not part of the item definition, so it's never overwritten by deployment. All value sets get deployed, but each target workspace has to pick its own active one. Switch it after deployment via the UI or the Variable Library API (updateMyActiveValueSet / PATCH on the variable library), which you can wire into your ADO pipeline as a final step.
So today: neither is handled natively by a single push from DevOps. The working pattern is deploy → rebind / activate as a post-step using Fabric CLI + REST API calls in the same YAML pipeline.
Useful links:CI/CD for Fabric using Azure DevOps & fabric-cicd
Variable library lifecycle / CI/CD
Value sets in variable libraries
Fabric CLI – item examples
Fabric ADO ExtensionDid this answer hit the mark? A small Kudos goes a long way — it fuels the community and encourages more folks to contribute.
Got what you needed? Marking this as the Accepted Solution helps others land on the right answer faster when they search for the same thing.
6 Replies
- Vinodh247
Super User
I believe this is a known gap in Fabric CI/CD today. When you deploy via azure DevOps or Fabric CLI, semantic models do not automatically rebind to the target Lakehouse and variable libraries do not switch environments because connection bindings and environment context are not fully parameterised in the deployment artefacts yet. The deployment pipeline moves the metadata, but not the runtime bindings. The practical workaround is a post-deployment step: explicitly rebind the semantic model to the target Lakehouse using the Fabric REST API (or PBI rebind API for datasets) and update the variable library/env mapping via script. In short, you cannot rely on native DevOps deployment alone for this; you must add an automated post deploy fix to handle bindings and env specific configuration.
Dev_DholakiaResolver IV
Hi BalfourBen ,
Both behaviors are expected right now, not a pipeline bug.
Semantic Model pointing to source workspace – The model definition in Git carries the original SQL endpoint connection string and database GUID. fabric-cicd and Fabric CLI don't rebind it automatically. You have to either parameterize it in parameter.yml (a find_replace for the connection string + the DB id) or rebind it post-deploy using the new Bind Semantic Model Connection REST API. Common pattern: deploy everything except the semantic model first, grab the new Lakehouse SQL endpoint id via fab api, inject it into parameter.yml, then deploy the model.
Variable Library reverting to "default" – The active value set is a per-workspace configuration, not part of the item definition, so it's never overwritten by deployment. All value sets get deployed, but each target workspace has to pick its own active one. Switch it after deployment via the UI or the Variable Library API (updateMyActiveValueSet / PATCH on the variable library), which you can wire into your ADO pipeline as a final step.
So today: neither is handled natively by a single push from DevOps. The working pattern is deploy → rebind / activate as a post-step using Fabric CLI + REST API calls in the same YAML pipeline.
Useful links:CI/CD for Fabric using Azure DevOps & fabric-cicd
Variable library lifecycle / CI/CD
Value sets in variable libraries
Fabric CLI – item examples
Fabric ADO ExtensionDid this answer hit the mark? A small Kudos goes a long way — it fuels the community and encourages more folks to contribute.
Got what you needed? Marking this as the Accepted Solution helps others land on the right answer faster when they search for the same thing.
BalfourBenThank you for your help I have managed to resolve using all these responses!
- BalfourBen
Thank you for your help I have managed to resolve using all these responses!
- Omkar_1712
Solution Specialist
Hello BalfourBen,
This is expected behavior with the current Fabric CI/CD experience.
Deploying the artifacts copies the semantic model and Variable Library, but environment-specific bindings are not automatically updated.A typical approach is:
Deploy the artifacts using Fabric CLI or Azure DevOps.
Rebind the semantic model to the target Lakehouse or Warehouse in the destination workspace using the Fabric/Power BI REST API as a post-deployment step.
Update the Variable Library (or reassign the target Environment) through automation so it points to the correct environment-specific values.
In other words, the deployment pipeline should be:
Deploy → Rebind Semantic Model → Update Variable Library → Validate
This ensures the semantic model connects to the destination Lakehouse and the Variable Library uses the correct environment-specific configuration instead of retaining the source/default settings.
If you're looking for a fully automated DevOps process, I'd recommend adding these rebinding and configuration steps to your release pipeline after the Fabric CLI deployment.
Best regards,
Omkar Shinde
Microsoft Fabric Enthusiast | Power BI Consultant
💡 If you found this response helpful, please consider giving it a Kudos.
✅ If this resolves your question, please mark it as the Accepted Solution to help others in the community.- BalfourBen
Thank you for your help I have managed to resolve using all these responses!
