Forum Discussion
Post PatronDirectLake in Onelake Vs DirectLake SQL End Point (Scope and Permissions)
Dear,
I have created a Gold layer which is composed by different workspaces.
Each workspace hosts a Domain (master data, supply chain, sales, etc..)
Each workspace as inside , at least , one lakehouse
Lakehouses, between them, even in different worskpaces, inside the gold layer, can use shortcuts to connect to each other, which means that I can do re-usability of objects
Now on top of this I am designing the semantic layer
I am considering using DirectLake one OneLake, for the semantic model, not the old DirectLake via SQL End Point
This because, if I am not wrong, with Directlake via Onelake, I can get in the same semantic model , tables from different lakehouses of the gold layer, even if they are in different worskpaces . Is this correct?
Andf I think it makes sense to have RLS in terms of permissions. Where are those created if I use DirectLake via OneLake?
Are they created on the semantic model itself? or do I need to inforce them via each lakehouse using the new funcionality : OneLake sercurity?
How does it work exactly?
Thanks a lot,
Pedro
Yes, 3 options :
A) first one, bring all tables you need into one lakehouse, you can use shortcuts for that and create your semantic model.
B) There is a preview direct lake feature which can use multiple lakehouses. https://powerbi.microsoft.com/nb-no/blog/deep-dive-into-direct-lake-on-onelake-and-creating-direct-lake-semantic-models-in-power-bi-desktop/
C) Use import mode for model semantic.
Hope it can help you!
Antoine
7 Replies
KevinChantSuper User
In part it depends on where you want the security rules applied. If you want the security respected amongst a variety of Fabric items then look to use OneLake security.
OneLake security overview - Microsoft Fabric | Microsoft Learn
- AntoineW
When you use Direct Lake on OneLake:
A semantic model can reference multiple Delta tables
Those tables can come from:
Different Lakehouses
Different Workspaces
As long as:
The tables are accessible through OneLake paths
Or exposed via Shortcuts into a single logical namespace
OneLake Security:
You create roles in lakehouse for example and give them access to what you want :
Controls object-level access
- Controls row-level security
- Control column level security
Official Microsoft References
Direct Lake in Power BI / Fabric
https://learn.microsoft.com/power-bi/enterprise/directlake-overviewOneLake and shortcuts
https://learn.microsoft.com/fabric/onelake/onelake-overviewOneLake security model
https://learn.microsoft.com/fabric/onelake/onelake-securityRLS in semantic models
https://learn.microsoft.com/power-bi/enterprise/service-admin-rls
Hope it can help you!
Best regards,
Antoine
fabricpribeiroDidn't understood.
Let me ask please, in another way
If I have two lakehouses, one in each workspace (two different workpsaces) in the same fabric tenant, can I bring both tables into the same semantic model if I use OneLake DirectLake ?
Thanks,
Pedro
Thanks,
Pedro
- AntoineW
Yes, 3 options :
A) first one, bring all tables you need into one lakehouse, you can use shortcuts for that and create your semantic model.
B) There is a preview direct lake feature which can use multiple lakehouses. https://powerbi.microsoft.com/nb-no/blog/deep-dive-into-direct-lake-on-onelake-and-creating-direct-lake-semantic-models-in-power-bi-desktop/
C) Use import mode for model semantic.
Hope it can help you!
Antoine
Hi fabricpribeiro ,
Thank you for reaching out to the Microsoft Fabric Community Forum.
Could you please let us know if the issue has been resolved? I wanted to check if you had the opportunity to review the information provided by AntoineW. If you still require support, please let us know, we are happy to assist you.
Thank you.
- cengizhanarslan
If you build the semantic model as DirectLake on OneLake, the model reads Delta files in OneLake. That makes it much easier to combine tables coming from multiple Lakehouses / multiple workspaces as long as the model identity has access to those OneLake locations (typically via shortcuts/OneLake access and workspace identity). You’re not forced to go through a single SQL endpoint.
DirectLake on SQL endpoint is different: you’re effectively building the model from a single SQL analytics endpoint (Lakehouse SQL endpoint or Warehouse). It’s more “database-like” and usually keeps you anchored to that endpoint’s scope and permissions.
On security:
RLS is always defined in the semantic model (roles + DAX filters). That doesn’t change whether you use OneLake or SQL endpoint.
OneLake security (item/OneLake data access) is a separate layer: it controls whether the model (or user/identity) can even read the files/objects in OneLake in the first place.
So in practice you usually use both, for different purposes:
Use OneLake/workspace permissions to control who/what can access the data at all (and to allow the model to read across workspaces).
Use RLS in the semantic model to control what a viewer can see inside the report/model.
Hi fabricpribeiro ,
We haven’t received an update from you in some time. Could you please let us know if the issue has been resolved?
If you still require support, please let us know, we are happy to assist you.Thank you.
