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.
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.
Hi SivaReddy86421 ,
I hope the information provided has been useful. Please let me know if you need further clarification or would like to continue the discussion.
Thank you.Hi v-tejrama
Thank you for the Information. I need some help on the below
- If views are created in LA and SELECT permission is granted to a user from LB, how would the user access those views? Would providing SELECT permission alone be sufficient or would we also need to grant the user access to the LA Lakhouse.?
Thanks,
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.Hi SivaReddy86421 ,
I wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions.
Thank you.