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 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.