Forum Discussion
Helper IIOneLake security behavior with Dataverse Fabric Link shortcut table
We’re looking for guidance / best practice confirmation for a security + sharing scenario involving Dataverse → Fabric Link → Lakehouse shortcut tables → OneLake Security roles → downstream Lakehouse consumption.
Architecture / Setup
- We have a Fabric Lakehouse (LH1).
- LH1 contains tables coming from Dynamics 365 / Dataverse via Fabric Link to Dataverse (Power Apps).
- In LH1, these show up as shortcut tables (not physical “materialized” Delta tables stored directly in LH1).
- We want to share only a subset of tables in LH1 with downstream users (not the entire Lakehouse).
What we did
- We used OneLake security roles on LH1 (shortcuts) to grant users access to only selected tables.
- We created new lakehouse LH2 with shortcuts to LH1, for the selected tables
Question
In this specific scenario (Dataverse via Fabric Link → shortcut tables in a Lakehouse), we are able to select a subset of shortcut tables using OneLake Security roles on the source Lakehouse (LH1). However, in most other scenarios where shortcut tables are used as the source for another shortcut, defining permissions at the table level is not allowed — the table selection is greyed out with the message:
“For OneLake shortcuts, the permissions must be defined in the destination table. Defining permissions on the shortcut itself is not allowed. Defining permissions on the shortcut itself is not allowed.”
Given this apparent difference in behavior, it would be helpful to understand:
- Whether this table‑level selection via OneLake Security roles is intended and supported for Dataverse Fabric Link shortcut tables?
- And more broadly, what the recommended best practice is to share only a subset of tables from LH1 when the source tables are shortcuts (especially Dataverse‑backed), without granting the whole Lakehouse (LH1) to users
Hi stellahe102,
This is actually a really interesting edge case in Microsoft Fabric OneLake Security, and honestly one of the areas where the behavior can still get a bit confusing in real-world architectures.
From what I’ve seen (and based on the current documentation), OneLake Security is enforced at the OneLake path level, but shortcut behavior changes depending on where the shortcut comes from and which engine is accessing it.
A few important nuances :
• Fabric-to-Fabric Lakehouse shortcuts
For regular OneLake shortcuts between Lakehouses, OneLake Security applies on the shortcut path itself.
That said, access is still ultimately tied to the source Lakehouse/path permissions underneath.• Dataverse shortcuts via Fabric Link
This scenario is a bit more nuanced because Fabric Link exposes Dataverse data into OneLake through managed linked structures backed by Dataverse export mechanisms.In practice, OneLake Security can restrict Fabric-side access to those shortcut paths, but it doesn’t replace or override the underlying Dataverse security model behind the scenes.
• Your LH1 → LH2 approach
Honestly, this is a pretty solid pattern.Using LH2 as a curated Lakehouse containing only approved shortcuts from LH1 is actually a clean way to implement selective sharing for downstream consumers.
One important thing to keep in mind though:
if OneLake Security is enabled on LH1, the shortcuts exposed through LH2 still depend on the upstream permissions from LH1.
So users accessing data through LH2 may still need access to the secured paths in LH1 itself.Also worth noting: in more advanced shortcut and cross-engine scenarios, enforcement behavior can still vary depending on the access path being used (Spark, SQL endpoint, Direct Lake, OneLake API, etc.), so it’s worth validating the behavior end-to-end with the exact consumption pattern you expect downstream.
Doc : https://learn.microsoft.com/fabric/onelake/security/get-started-onelake-security
Hello stellahe102 , thanks for your feedback.
That’s actually the key nuance in this scenario 🙂
From what you describe, granting access only on LH1 may not always be sufficient, especially when the access path goes through shortcut resolution and Dataverse Fabric Link tables.
What makes this tricky is that shortcut authorization is evaluated dynamically depending on :
- the engine being used (SQL endpoint, Spark, Direct Lake, etc.)
- the identity context and where the query is ultimately resolved.
If users are seeing inconsistent access from LH2 to tables physically exposed through LH1 shortcuts, I would strongly suspect a permission propagation or evaluation gap between :
- LH2 permissions
- LH1 shortcut access and the underlying Dataverse-linked storage/security context.
In practice, I would validate all 3 layers explicitly :
- Access to LH2
- Read access to LH1 (where the shortcuts live)
- Underlying Dataverse/Fabric Link permissions if applicable
I’ve seen cases where shortcuts appear visible in the consumer lakehouse, but query execution still validates permissions against the source lakehouse hosting the shortcut metadata.
So yes based on the inconsistent behavior you’re observing, I would not assume LH2 only access is enough here. This is also one of those areas where OneLake shortcut security behavior can still feel inconsistent depending on the access path and feature combination involved (Dataverse Link + shortcuts + Lakehouse cross-access).
Hope this helps you troubleshoot the issue 🙂
Don’t hesitate to share your feedback or what finally worked on your side.
6 Replies
v-menakakotaCommunity Support
Hi stellahe102 ,
Thanks for reaching out to the Microsoft fabric community forum.
I would also take a moment to thank Tamanchu , for actively participating in the community forum and for the solutions you’ve been sharing in the community forum. Your contributions make a real difference.
I hope the above details help you fix the issue. If you still have any questions or need more help, feel free to reach out. We’re always here to support you.Best Regards,
Community Support Team- v-menakakota
Hi stellahe102 ,
I hope the above details help you fix the issue. If you still have any questions or need more help, feel free to reach out. We’re always here to support you.
Best Regards,
Community Support Team
- Tamanchu
Super User
Hi stellahe102,
This is actually a really interesting edge case in Microsoft Fabric OneLake Security, and honestly one of the areas where the behavior can still get a bit confusing in real-world architectures.
From what I’ve seen (and based on the current documentation), OneLake Security is enforced at the OneLake path level, but shortcut behavior changes depending on where the shortcut comes from and which engine is accessing it.
A few important nuances :
• Fabric-to-Fabric Lakehouse shortcuts
For regular OneLake shortcuts between Lakehouses, OneLake Security applies on the shortcut path itself.
That said, access is still ultimately tied to the source Lakehouse/path permissions underneath.• Dataverse shortcuts via Fabric Link
This scenario is a bit more nuanced because Fabric Link exposes Dataverse data into OneLake through managed linked structures backed by Dataverse export mechanisms.In practice, OneLake Security can restrict Fabric-side access to those shortcut paths, but it doesn’t replace or override the underlying Dataverse security model behind the scenes.
• Your LH1 → LH2 approach
Honestly, this is a pretty solid pattern.Using LH2 as a curated Lakehouse containing only approved shortcuts from LH1 is actually a clean way to implement selective sharing for downstream consumers.
One important thing to keep in mind though:
if OneLake Security is enabled on LH1, the shortcuts exposed through LH2 still depend on the upstream permissions from LH1.
So users accessing data through LH2 may still need access to the secured paths in LH1 itself.Also worth noting: in more advanced shortcut and cross-engine scenarios, enforcement behavior can still vary depending on the access path being used (Spark, SQL endpoint, Direct Lake, OneLake API, etc.), so it’s worth validating the behavior end-to-end with the exact consumption pattern you expect downstream.
Doc : https://learn.microsoft.com/fabric/onelake/security/get-started-onelake-security
stellahe102Thanks Tamanchu for your reply. Based the set up mentioned in the original message, User observes inconsistent access to the tables in their own lakehouse (LH2), so the question comes if granting them access on the source lakehouse (LH1, which only has shortcut tables pointing to dataverse) is sufficinet enough.
- Tamanchu
Hello stellahe102 , thanks for your feedback.
That’s actually the key nuance in this scenario 🙂
From what you describe, granting access only on LH1 may not always be sufficient, especially when the access path goes through shortcut resolution and Dataverse Fabric Link tables.
What makes this tricky is that shortcut authorization is evaluated dynamically depending on :
- the engine being used (SQL endpoint, Spark, Direct Lake, etc.)
- the identity context and where the query is ultimately resolved.
If users are seeing inconsistent access from LH2 to tables physically exposed through LH1 shortcuts, I would strongly suspect a permission propagation or evaluation gap between :
- LH2 permissions
- LH1 shortcut access and the underlying Dataverse-linked storage/security context.
In practice, I would validate all 3 layers explicitly :
- Access to LH2
- Read access to LH1 (where the shortcuts live)
- Underlying Dataverse/Fabric Link permissions if applicable
I’ve seen cases where shortcuts appear visible in the consumer lakehouse, but query execution still validates permissions against the source lakehouse hosting the shortcut metadata.
So yes based on the inconsistent behavior you’re observing, I would not assume LH2 only access is enough here. This is also one of those areas where OneLake shortcut security behavior can still feel inconsistent depending on the access path and feature combination involved (Dataverse Link + shortcuts + Lakehouse cross-access).
Hope this helps you troubleshoot the issue 🙂
Don’t hesitate to share your feedback or what finally worked on your side.
- sabledattatray
Advocate II
This is a known architectural challenge when mixing OneLake folder-level security with external shortcuts like the Dataverse Fabric Link.
Here is exactly why this happens and the best practice design to handle it:
Point 1: The target security boundary When you define a OneLake Data Access Role on the shortcut folder in LH1, you are only securing the metadata pointer inside that Lakehouse. However, a shortcut is just a link to external storage managed by Dataverse. When a downstream user queries the shortcut, the Fabric query engine must resolve permissions at the underlying target storage. If the user does not have read permissions on the target Dataverse environment, the query fails at the storage level even if your OneLake role allows them to see the folder.
Point 2: SQL Endpoint limitation OneLake folder-level security roles are currently not supported for external shortcuts when queried through the SQL Analytics Endpoint or Power BI semantic models. The SQL Endpoint uses a service identity that bypasses granular folder-level roles on shortcuts, which can lead to users either seeing all data or experiencing complete access blocked errors.
Point 3: The recommended architecture Instead of sharing the shortcut tables directly using OneLake roles, the best practice is to separate your ingestion lakehouse from your consumption lakehouse:
First, keep LH1 as your raw ingestion layer where the Dataverse Fabric Link writes all your shortcut tables. This should be restricted to administrators and your data engineering team only.
Second, create a separate downstream Lakehouse for your business users.
Third, use a simple pipeline or a Spark notebook to copy or clone only the allowed subset of tables from LH1 into the downstream Lakehouse as standard, physical Delta tables. You can automate this to run on a schedule or trigger it when files update.
By copying the data into the downstream Lakehouse, you remove the external Dataverse connection dependencies. This guarantees that your folder-level security roles, the SQL Analytics Endpoint, and Power BI semantic models will work perfectly for your business users.
Let me know if this helps clarify the security model and design pattern!
