Unable to refresh data from table shortcut

[tp_forever]

I have a table shortcut to ADLS2 in Fabric Lakehouse. I can query the data by using SQL Endpoint. However, if I try to put that table into DirectLake dataset, then I get error:

InnerException1.Stack Trace Message: Failed to save modifications to the server. Error returned: 'We cannot refresh this semantic model because one or multiple source tables either do not exist or access was denied. Please contact a data source admin to verify that the tables exist and ensure that the owner of this semantic model does have read access to these tables: '<oii>Samples</oii>'

I tried:

1. Enabling Workspace Identity and granting it "Read" and "Storage Blob Data Reader" access to blob storage where that data actually resides.
2. Tried granting my user same access as above.
3. Granted Workspace Identity and myself access to the Fabric connection that is used by the shortcut.
4. My user is admin user in Fabric.
5. Added normal table to dataset and it was refreshed successfully.

Any ideas?

[rohit1991 · Accepted solution]

Hii @tp_forever 

This is a DirectLake limitation, not a permissions issue. DirectLake semantic models currently do not support refreshing tables that come from ADLS shortcuts. While shortcuts work via the Lakehouse SQL Endpoint, DirectLake reads Delta files directly from OneLake and cannot resolve shortcut-backed tables during refresh. This is why normal Lakehouse tables refresh successfully but shortcut tables fail.Materialize the shortcut into a physical table in the Lakehouse, switch the model to Import mode, or use a Warehouse instead. Permissions and workspace identity changes will not resolve this issue.

[v-veshwara-msft]

Hi @tp_forever ,

Thanks for reaching out to Microsoft Fabric Community.
Just wanted to check if the responses provided were helpful. If further assistance is needed, please reach out.
Thank you.

[cengizhanarslan · Accepted solution]

According to the Microsoft Direct Lake documentation, there are two different Direct Lake modes, and this distinction is what explains the behavior you’re seeing:
https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview

1) Direct Lake on OneLake
This mode reads native Lakehouse Delta tables directly from OneLake and completely bypasses SQL.
In this mode, ADLS Gen2 shortcuts are not supported, because Direct Lake validates physical Delta files stored in the Lakehouse. Shortcuts fail this validation and cause refresh errors.

2) Direct Lake on SQL (Analytics Endpoint)
This mode uses the Lakehouse SQL analytics endpoint to discover and validate tables.
It can work with objects exposed through SQL, and can fall back to DirectQuery when needed. This is the mode referenced in the documentation when SQL endpoint support is mentioned.

If your semantic model was created in Direct Lake on OneLake, shortcuts will fail even though they can be queried via SQL. 

How to check / choose the mode
The mode is determined when the semantic model is created:

• Creating the model directly from Lakehouse tables → Direct Lake on OneLake

  • Go to the Lakehouse, select New semantic model, and pick tables directly from the Lakehouse explorer

• Creating the model from the Lakehouse SQL analytics endpoint or a Warehouse → Direct Lake on SQL

  • Get data → Fabric → Lakehouse SQL endpoint

If shortcuts are required, verify which Direct Lake mode your model is using and recreate the semantic model using the SQL analytics endpoint, or materialize the shortcut into a native Lakehouse table.

[rohit1991 · Accepted solution]

Hii @tp_forever 

This is a DirectLake limitation, not a permissions issue. DirectLake semantic models currently do not support refreshing tables that come from ADLS shortcuts. While shortcuts work via the Lakehouse SQL Endpoint, DirectLake reads Delta files directly from OneLake and cannot resolve shortcut-backed tables during refresh. This is why normal Lakehouse tables refresh successfully but shortcut tables fail.Materialize the shortcut into a physical table in the Lakehouse, switch the model to Import mode, or use a Warehouse instead. Permissions and workspace identity changes will not resolve this issue.