Forum Discussion
Direct Lake on OneLake + Deployment Pipelines + Git: parameter rules deploy but semantic model refre
Hi all,
I’m trying to make a Fabric / Power BI semantic model deployment flow work for Dev -> Prod with Git and Deployment Pipelines, but I’m stuck on Direct Lake on OneLake source rebinding.
Setup:
I have two Fabric workspaces:
DEV workspace: TPA-BI-Hub-Dev
DEV lakehouse: lh_tpa_bi_hub
PROD workspace: TPA-BI-Hub
PROD lakehouse: lh_tpa_bi_hub
The semantic model is a Direct Lake on OneLake model. In TMDL, the source expression uses:
AzureStorage.DataLake(
"https://onelake.dfs.fabric.microsoft.com/<workspace-id>/<lakehouse-id>",
[HierarchicalNavigation=true]
)
Tables have Direct Lake partitions, for example:
partition dim_kontakt = entity
mode: directLake
source
entityName: dim_kontakt
schemaName: gold
expressionSource: 'DirectLake - lh_tpa_bi_hub'
Microsoft docs say Direct Lake on OneLake does not directly support deployment pipeline data source rebinding rules, but a parameter expression can be used in the connection string.
Reference:
https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview
Attempt 1: split parameters
We changed the expression to:
AzureStorage.DataLake(
"https://onelake.dfs.fabric.microsoft.com/" & WorkspaceId & "/" & LakehouseId,
[HierarchicalNavigation=true]
)
with parameter rules in the Production stage:
WorkspaceId = <PROD workspace id>
LakehouseId = <PROD lakehouse id>
The model deployed and showed data, but refresh/reframe failed with:
DirectQuery schema evaluation is not supported by the service-side ServiceLegacySchemaEvaluations.
DirectQuery schema evaluation is a desktop-only path.
Attempt 2: single full URL parameter
Based on community examples, we changed to:
expression 'DirectLake - lh_tpa_bi_hub' =
let
Source = AzureStorage.DataLake(#"OneLakeSource", [HierarchicalNavigation=true])
in
Source
expression OneLakeSource =
"https://onelake.dfs.fabric.microsoft.com/<DEV workspace id>/<DEV lakehouse id>"
meta [IsParameterQuery = true, Type = "Text", IsParameterQueryRequired = true]
annotation PBI_ResultType = Text
Then Production parameter rule:
OneLakeSource =
https://onelake.dfs.fabric.microsoft.com/<PROD workspace id>/<PROD lakehouse id>
But Fabric validation failed with:
ConceptualSchemaSettings should not be provided for non-Direct Lake queries
That sounds like the service no longer classifies the parameterized expression as Direct Lake, even though the table partitions are still mode: directLake.
Questions:
1. What is the recommended Git-compatible Dev -> Prod deployment pattern for Direct Lake on OneLake semantic models?
Specifically:
2. Is parameterizing AzureStorage.DataLake(...) officially supported for semantic model refresh/reframe in the Power BI service, or only for deployment-time rule substitution?
3. Is the single URL parameter pattern expected to work with Git-integrated semantic models and Deployment Pipelines?
4. If parameter rules are unreliable here, is the recommended approach to maintain environment-specific branches, e.g.:develop has static DEV OneLake URL
main / release-prod has static PROD OneLake URL
5. Or should we migrate to Direct Lake on SQL endpoint to use deployment pipeline data source rules properly?
Related sources I found:
Microsoft Direct Lake overview: https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview
Microsoft Direct Lake development/TMDL source types: https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-develop
Community example using OneLakeURI parameter: https://www.datazoe.blog/post/deployment-pipelines-and-power-bi-semantic-models-with-direct-lake-on-onelake-tables
Direct Lake on OneLake vs SQL identification: https://data-mozart.com/direct-lake-models-are-they-onelake-or-sql-and-how-to-check/
Any confirmation of a working production-grade pattern would be very helpful.
3 Replies
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
Thanks, this is only way which I am seeing it is working for now...so post merge script handling parameters...
Hi jaryszek
Thank you for sharing the detailed information and the troubleshooting you've already performed.
Based on your findings, this appears to be related to the current behavior and supported capabilities of Direct Lake on OneLake with Git integration and Deployment Pipelines. Since this scenario isn't fully documented, I recommend opening a Create a Fabric and Power BI Support Ticket - Power BI | Microsoft Learn so the product team can confirm whether this is expected behavior/known limitation or a product issue requiring further investigation.
