Creating a shortcut on a view

[SivaReddy86421]

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:

1. 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.
2.  Creating Materialized Views
   • This would create physical tables based on the views, and those tables can potentially be shortcutted.
3.  Creating the Views in the Users Lakehouse LB.

suggest if there is a better alternative?

Thank you,

Siva Reddy

[Srisakthi]

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

[SivaReddy86421]

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

[Srisakthi]

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

[SivaReddy86421]

@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

[v-tejrama]

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.

[SivaReddy86421]

Hi @v-tejrama 

Thank you for the Information. I need some help on the below

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

[v-tejrama · Accepted solution]

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?ut...
https://learn.microsoft.com/en-us/fabric/data-engineering/lakehouse-shortcuts?utm_source

Thank you.

[v-tejrama]

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.

[v-tejrama]

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.