Forum Discussion
Creating a shortcut on a view
I’m currently working on rebuilding the views that we have in SQL. The base tables are already available in the Fabric Lakehouse (LA), and now I’m looking into options for recreating the views.
I have identified the following approaches and would like to clarify a few points:
- Creating the views in the SQL Endpoint
- We cannot create shortcuts for these views for users working in another Lakehouse (LB).
- These views also cannot be accessed through notebooks.
- Creating Materialized Views
- This would create physical tables based on the views, and those tables can potentially be shortcutted.
- Creating the Views in the Users Lakehouse LB.
suggest if there is a better alternative?
Thank you,
Siva Reddy
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.
9 Replies
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
