Direct Lake on OneLake + Deployment Pipelines + Git: parameter rules deploy but semantic model refre

jaryszek​ 

One solution I'd suggest is to deploy your code through Azure DevOps Pipelines alongside Fabric's Git integration, instead of relying on Fabric/Power BI Deployment Pipelines' parameter rules.

Assuming your DEV and PROD workspaces are Git-integrated, keep placeholder tokens for the workspace ID and lakehouse ID in your TMDL source, something like WORKSPACE_ID and LAKEHOUSE_ID, in your feature branches. This keeps the files environment-agnostic and avoids merge conflicts across branches.

When a PR is completed into your dev or prod branch, trigger an Azure DevOps pipeline that runs a post-merge script to find and replace those tokens with the real workspace ID and lakehouse ID for that environment, stored as pipeline variables, a variable group. The pipeline then commits and pushes that resolved file back into the target branch.

Fabric's own Git integration, connected to that branch, picks up the new commit and syncs it into the workspace as usual. So the ADO pipeline isn't doing the actual deployment, it's just resolving the placeholders into real IDs right before Fabric's Git sync runs.

This replace-and-commit step can be fully automated, no manual intervention needed. You can use a native PowerShell task in the pipeline (docs: https://learn.microsoft.com/en-us/azure/devops/pipelines/scripts/powershell), or the Replace Tokens extension from the marketplace if you'd rather keep it declarative in YAML. Either way it runs automatically on PR completion.

Hope this helps