Forum Discussion
Creating a shortcut on a view
Hi SivaReddy86421 ,
Thank you for your follow-up question, as this aspect of Fabric access can be complex.
Granting SELECT permission on a view alone is not sufficient if the user does not already have access to the Lakehouse or its SQL analytics endpoint where the view resides. Since the view is located in LA, the user must first have access to LA’s SQL endpoint. After access is granted, you can use SQL permissions to limit their access to specific views rather than exposing all objects.
To clarify, users from LB would connect directly to LA’s SQL endpoint to query the views. They would not access these views through shortcuts in LB, as shortcuts do not support logical objects such as views.
If users are required to work exclusively in LB and should not access LA, this method will not fully address your needs. In this case, the recommended approach is to persist the view output as physical Delta tables in LA and share these tables with LB using shortcuts.
Ultimately, your decision should be based on your access model. If users can access LA’s SQL endpoint, maintaining views in LA is the preferred option. If users must stay within LB, creating physical tables is necessary, as views cannot currently be shared across Lakehouses using shortcuts.
For further details, please refer to Microsoft’s documentation on SQL endpoint permissions and shortcut behavior:
https://learn.microsoft.com/en-us/fabric/onelake/security/sql-analytics-endpoint-onelake-security?utm_source
https://learn.microsoft.com/en-us/fabric/data-engineering/lakehouse-shortcuts?utm_source
Thank you.
Hi SivaReddy86421 ,
Your are correct. We cannot create shortcut on views.
Can you elaborate the use of Views? Depending on the requirement we can decide whether to have materialised views or views in lakehouse(LB).
Just want to highlight as per doc Materialised Views are not in South Central US region
Materialized lake views aren't the right choice for every scenario. Consider alternatives when you have:
- One-time or rarely accessed queries that don't benefit from precomputed results
- Simple transformations that already run quickly without optimization
- Non-SQL logic such as ML inference, API calls, or complex Python processing — use Spark notebooks instead
- High-frequency streaming data that requires sub-second updates — consider Real-Time Intelligence instead
Based on the above points consider materialised views. It requires refresh after data loading. In case of normal views there is no separate refresh required but it will compure the result everytime when it is accessed.
Regards,
Srisakthi
Hi Srisakthi
These views do not contain any complex logic, they are primarily simple joins between a couple of tables with selected fields. So, I don’t think materialized views are required for this use case.
The idea of replicating these views in Fabric is mainly to store the view logic centrally within Fabric, so that users can reuse the same logic either through notebooks or via the SQL endpoint for analysis.
More Details:
- We have a Lakehouse (LA) where we land data from SQL and share shortcuts to users in Lakehouse (LB).
- We are planning to replicate the views currently available in SQL into the Fabric Lakehouse (LA). The access to these will then be shared with users through Lakehouse (LB).
Hi SivaReddy86421 ,
Thanks for clarifying it. You are correct as your views doesnt have complex logic/transformation no point in using materialised views.
So are you going to create views in Lakehouse(LA) and grant access to only specific users ?
Have you explored SQL level grant permission? May be this can help
Regards,
Srisakthi
We are you going to create views in Lakehouse(LA) and grant access to only specific users via Lakehouse(LB).
- Building the View in Lakehouse LA and moving the same logic to Lakehouse LB is one work around.
I am yet to explore SQL level grant permission and will confirm if this works. Thank you
Hi SivaReddy86421 ,
Thank you for providing the additional information. Based on your requirements, I would not suggest using materialized views, as your logic involves straightforward joins and column selections. Implementing materialized views would introduce unnecessary refresh and maintenance overhead without significant advantages.
It is important to note that shortcuts in Fabric are only applicable to physical Lakehouse objects such as tables and files. Since views are logical objects, they cannot be shortcutted to another Lakehouse, making that approach unsuitable in this scenario.
If centralizing the logic in LA is your objective, I recommend creating the views in LA’s SQL endpoint and granting users access via SQL permissions. This approach ensures the logic remains consolidated and avoids duplicating views across multiple Lakehouses.
For notebook access, users can connect to the SQL endpoint and query the views directly if access is infrequent. However, if frequent notebook access in LB is required, it would be more effective to create curated Delta tables from those joins, as physical tables can be shared using shortcuts.
In summary, maintaining the views in LA and managing access through permissions is advisable unless frequent notebook access from LB is essential. Duplicating views across Lakehouses would result in unnecessary maintenance effort.
Here are the relevant Microsoft document for your scenario:https://learn.microsoft.com/en-us/fabric/data-engineering/lakehouse-shortcuts?utm_source
Thank you.