Forum Discussion
Shortcut table visible in SQL endpoint but not accessible as a standard lakehouse table
I’m working with Microsoft Fabric and have the following setup:
- Workspace A: Contains a Lakehouse with a table.
- I mirrored this table from Lakehouse in Workspace A to another Lakehouse in Workspace B.
Here’s the issue:
Users who do not have access to Workspace A cannot access the shortcut table in Workspace B through the Lakehouse interface. However, when they connect to the SQL endpoint of Workspace B’s Lakehouse, they can see the table and its data
- Is this expected behavior?
Should shortcut tables appear in the SQL endpoint even if the user doesn’t have permissions on the original workspace?
Edit: Earlier version said "Mirrrored" insted of "Shortcut" Sorry!
Any insights or official documentation references would be greatly appreciated!
Hi AdarshChekodu ,
Building a semantic model and a Power BI report on top of the shortcut table is completely fine. We’ve tested the same setup, and the semantic model can read the shortcut data without any issues, even when the user doesn’t have access to the original workspace. The SQL endpoint treats the shortcut as a normal table in the destination Lakehouse, so the model refresh and report queries work as expected.
Regarding whether this behaviour will be changed: right now this is considered expected. A shortcut shows up fully in the SQL endpoint because the SQL layer relies on the metadata of the destination Lakehouse, not the source workspace. But the Lakehouse UI is stricter and checks the source permissions, which is why users without access to Workspace A can’t open the shortcut there.
Microsoft hasn’t announced a change yet, but this is something they’re aware of. If they do update it in the future, it will likely be in the direction of making the UI and SQL endpoint consistent — but as of now, this is how it works.
Hope this helps. If so, please give a Kudos 👍 or mark as Accepted Solution ✔️
– Gopi Krishna
8 Replies
Hi AdarshChekodu ,
We ran into the same behaviour when testing mirrored tables between two workspaces, and what you’re seeing is actually how Fabric works today. A mirrored table becomes a physical object inside the target Lakehouse, and because of that, its metadata automatically shows up in the SQL endpoint of the destination workspace. So even if a user has no access to the original workspace, they can still query the mirrored table through SQL because the table is now part of the destination Lakehouse’s SQL model.
The confusing part is that the Lakehouse UI is more strict. The UI still tries to validate the original source when showing the mirrored table under “Tables,” so users without permissions in the original workspace won’t see it there or will get access-related errors. But SQL doesn’t check that – it only looks at the local metadata and the mirrored storage files in the target workspace, so the query works fine.
When we asked internally, this was described as expected behaviour for the current version of mirroring: the SQL endpoint treats mirrored tables as independent objects, but the Lakehouse explorer hasn’t caught up yet in terms of access and visibility rules. So yes, it’s normal at the moment that the table is visible in SQL but not accessible from the Lakehouse UI unless the user also has access to the source workspace.
Hope this helps clear things up. Let me know if you want to compare setups we had almost the same situation during our testing.
Gopi Krishna
Hello Ugk161610 ,
I meant shortcut of the table, do you mean the same? Apologies for the typo in the question
Hi AdarshChekodu ,
We’ve run into this behaviour as well when working with shortcut tables across different workspaces, and yes — what you’re seeing is actually expected with the current design.
A shortcut only creates a reference to the underlying files in the source Lakehouse. So if a user doesn’t have access to Workspace A, the Lakehouse UI in Workspace B won’t let them browse or open that shortcut table, because the UI still tries to validate permissions against the original workspace. From the UI perspective, if you don’t have rights on the source, the table “doesn’t exist,” even though the shortcut is technically there.
However, the SQL endpoint works differently. When Fabric loads the metadata for the SQL endpoint, it only looks at the structure that exists inside Workspace B. It doesn’t re-check permissions for Workspace A before reading metadata. That’s why the user can query the shortcut table through SQL even though they can’t see it in the Lakehouse Explorer.
So in short:
– Lakehouse UI = requires source workspace permissions.
– SQL endpoint = reads shortcut metadata locally, so it works.It’s definitely a confusing experience, but it matches what we’ve seen. Shortcut tables behave like files linked across workspaces, and the UI is more strict about validating source permissions than the SQL endpoint.
Hopefully this gets improved in future updates, because the split behaviour can be hard to explain to users.
– Gopi Krishna
Hi AdarshChekodu, don't mind me asking, but why are you mirroring data from one Fabric Lakehouse to another and why are you not just making a shortcut in the Lakehouse B to the table in Lakehouse A? That way you are not duplicating data.
With the issue that you have, that users can see the table and it's data in Lakehouse B is expected behaviour, when you have assigned those users any workspace role. All assigned workspace role automatically have at least Read and ReadData on a SQL Endpoint. To overcome this, start using Org Apps and remove the assigned roles for users who only need to views reports.
Hope this helps. If so, please give a Kudos 👍 or mark as Accepted Solution ✔️.
nielsvdc Apologies; I meant shortcut. I created the table short cut. I missspoke it as mirroring. I will update the question
Hi,
If the user only have a viewer role of the Workspace B, this is expected. Please refer to "1 Viewer can only read data stored in tables using the SQL analytics endpoint provided SQL access policy is granted." in https://learn.microsoft.com/en-us/fabric/data-engineering/workspace-roles-lakehouse#lakehouse-workspace-roles-and-item-specific-functions
If the end users can see and use them in the Lakehouse interface, please refer to https://learn.microsoft.com/en-us/fabric/onelake/onelake-shortcut-security#shortcut-auth-models . This depends on the "Data access mode" setting.
