Share feedback directly with Fabric product managers, participate in targeted research studies and influence the Fabric roadmap.
Sign up nowGet Fabric certified for FREE! Don't miss your chance! Learn more
Hi,
We are working on a project to migrate data from dataflows to fabric.
I would like to use onelake security to manage security so we don't need to redesign security in the future.
Due to viewers of data needing viewer role on the workspace, I am testing out giving users access to shortcuts in a seperate workspace so they don't see integration items.
We want them to be able to import to reduce migration effort.
Unfortunately I can't see the shortcut tables when accessing the lakehouse using the SQL Endpoint (event with an elevated user).
Can anyone help me here? I'm also open to other suggestions in terms of a migration plan (we are migrating to lakehouse architecutre and want to adopt onelake security when ready, currently planning to use Semantic Model RLS on Onelake due to potential performance issues).
If we can't resolve this, then I will ignore onelake security for now and migrate users using SQL Security directly to the gold lakehouse.
Thanks in advance!
Solved! Go to Solution.
Hi @Louis020790,
Thank you for reaching out to the Microsoft Fabric Community Forum and thanks for explaining your scenario so clearly. Also, thanks to @deborshi_nag, @ssrithar, for those inputs on this thread.
You are not missing any configuration here. When One Lake security is enabled, shortcut tables (especially cross-workspace) are not surfaced through the SQL Endpoint, even for elevated users. This is because shortcuts use a passthrough authentication model and the SQL Endpoint does not yet fully evaluate path based One Lake permissions across shortcuts, so those tables are hidden rather than partially accessible.
Given your goal to migrate from Dataflows to a Lakehouse architecture while keeping Import mode and avoiding exposure of integration items, the supported and reliable approach right now is to materialize data into managed Lakehouse tables (Gold layer) and apply security at the SQL layer (GRANTs) or the Semantic Model layer (RLS), rather than using One Lake security with shortcuts. This aligns with current guidance for SQL Endpoint usage and Lakehouse consumption (Lakehouse SQL endpoint overview and Row-level security in Power BI semantic models on Microsoft Learn). You can then revisit One Lake security later, once SQL Endpoint support for One Lake ACLs and shortcut resolution is fully available, without needing to redesign your overall model.
Refer these links:
1. https://learn.microsoft.com/en-us/fabric/onelake/onelake-shortcut-security
2. https://learn.microsoft.com/en-us/fabric/onelake/sql-analytics-endpoint-onelake-security
Hope that clarifies. Let us know if you have any doubts regarding this. We will be happy to help.
Thank you for using the Microsoft Fabric Community Forum.
Hi @Louis020790,
Thank you for reaching out to the Microsoft Fabric Community Forum and thanks for explaining your scenario so clearly. Also, thanks to @deborshi_nag, @ssrithar, for those inputs on this thread.
You are not missing any configuration here. When One Lake security is enabled, shortcut tables (especially cross-workspace) are not surfaced through the SQL Endpoint, even for elevated users. This is because shortcuts use a passthrough authentication model and the SQL Endpoint does not yet fully evaluate path based One Lake permissions across shortcuts, so those tables are hidden rather than partially accessible.
Given your goal to migrate from Dataflows to a Lakehouse architecture while keeping Import mode and avoiding exposure of integration items, the supported and reliable approach right now is to materialize data into managed Lakehouse tables (Gold layer) and apply security at the SQL layer (GRANTs) or the Semantic Model layer (RLS), rather than using One Lake security with shortcuts. This aligns with current guidance for SQL Endpoint usage and Lakehouse consumption (Lakehouse SQL endpoint overview and Row-level security in Power BI semantic models on Microsoft Learn). You can then revisit One Lake security later, once SQL Endpoint support for One Lake ACLs and shortcut resolution is fully available, without needing to redesign your overall model.
Refer these links:
1. https://learn.microsoft.com/en-us/fabric/onelake/onelake-shortcut-security
2. https://learn.microsoft.com/en-us/fabric/onelake/sql-analytics-endpoint-onelake-security
Hope that clarifies. Let us know if you have any doubts regarding this. We will be happy to help.
Thank you for using the Microsoft Fabric Community Forum.
Hi,
Thank you for your response.
Am I correct that this limitation isn't listed in the documentation?
Hi @Louis020790,
You are correct, this specific behaviour isn’t explicitly listed as a named limitation in the Microsoft documentation. The current docs explain the individual building blocks (One Lake path-based security, shortcut passthrough authentication, and SQL analytics endpoint identity modes), but they don’t yet call out every interaction between them. In practice, when One Lake security is applied to shortcuts (especially across workspaces), the SQL analytics endpoint may not be able to fully resolve permissions during metadata synchronization, which can result in shortcut tables not being surfaced even for elevated users. This aligns with the documented security models, but the combined behaviour isn’t yet spelled out as a formal limitation.
That said, this isn’t an isolated case. Similar behaviour has been reported by other customers in the Fabric community, for example where shortcut tables don’t appear in the SQL analytics endpoint, or where One Lake security features (such as column-level security) don’t function as expected with shortcuts (Solved: Re: Unable to see the shortcuts in silver layer(sq... - Microsoft Fabric Community, Column Level OneLake Security - Not Working with s... - Microsoft Fabric Community). For this reason, the currently recommended and supported approach for consumption scenarios is to use managed Lakehouse tables with SQL permissions or semantic model RLS and consider adopting One Lake security at a later stage, once SQL endpoint support for shortcuts is more fully aligned.
Thank you for using the Microsoft Fabric Community Forum.
Please can you provide evidence to this limitation.
Hello @Louis020790
Here's a blog post on OneLake Security with Shortcuts. Best to keep in mind that Shortcuts use passthrough auth model, so your issue could be related to that.
Understanding OneLake Security with Shortcuts | Microsoft Fabric Blog | Microsoft Fabric
Thanks, but this doesn't help with my current issue.
My understanding is that anyone with Viewer role on a workspace should see all shortcuts (it doesn't matter if they don't have access to the target object), they just won't see any data when they query it.
My problem is a user with an admin role on the workspace is not able to see a shortcut (not the target data/object) when accessing via the sql endpoint with onelake security enabled on both source & shortcutted lakehouse (with onelake security enabled for SQL endpoints also).
Hi @Louis020790 ,
You’re running into a real, current Fabric limitation, not a misconfiguration — and your observation is correct.
Workaround
1. Ignore OneLake security for now
2. Semantic Model RLS as the primary security layer.
Since you’re migrating Dataflows and want Import mode:
Land data in managed Lakehouse tables
Expose via SQL endpoint
Apply:
SQL GRANTs or
Semantic Model RLS
Revisit OneLake security after SQL/OLS convergence improves
Trying to combine:
shortcuts
OneLake security
SQL endpoint
import mode
…will only slow you down today.
If this post helps, then please appreciate giving a Kudos or accepting as a Solution to help the other members find it more quickly.
If I misunderstand your needs or you still have problems on it, please feel free to let us know. Thanks a lot!
If you love stickers, then you will definitely want to check out our Community Sticker Challenge!
Check out the January 2026 Fabric update to learn about new features.
| User | Count |
|---|---|
| 24 | |
| 16 | |
| 11 | |
| 9 | |
| 6 |
| User | Count |
|---|---|
| 80 | |
| 69 | |
| 55 | |
| 24 | |
| 22 |