Forum Discussion
User to build Semantic Model using table granted via OneLake Data Access Role
Hi, we have a use case titled.
We shared only 1 table (Employee) in a lakehouse (LH_source) via the OneLake Data Access Role with a group. The users in that group can see and access that table in their lakehouse (LH_user) which has a shortcut to the Employee table in LH_Source, but when they try to pull the table to a new semantic model (see below screenshot) from the LH_user, they get error saying that table (Employee) is not accessible.
My understanding is the OneLake data access role should takes care of all the access whether use try to access it via lakehouse or SQL endpoint or semantic model, but what we observed conflicts this. Any idea why or we missed something from our end?
We also tried to share the whole lakehouse (LH_source) with the user group - via the route in below screenshot, and they can access table in a new semantic model, but this opens the whole lakehouse to the group, which is not what we wanted, as now they can pull any table in that LH_source via a shorcut in their own lakehouse. So anyway that we can allow the user to access only specific tables when building their own semantic model without having access to the whole source lakehouse?
Hi stellahe102 ,
Thanks for your detailed follow-up, your understanding is correct. To answer your questions: for Direct Lake semantic models, only Lakehouse Build permission is required to create a semantic model, users do not need the “Read All SQL Endpoint data” permission unless they are querying the SQL endpoint directly (Lakehouse Permissions - Microsoft Docs).
Regarding the second question, yes, you may create a shortcut in a separate Lakehouse that points to the Employee table. Just make sure users have Read permission on the source Lakehouse where the Employee table resides and Build permission on the new Lakehouse where they are creating the semantic model.
Finally, if someone else creates the semantic model and shares it, this also works. As per my knowledge, If the semantic model is in Direct Lake mode, users might still need Read permission on the Lakehouse at runtime to query the data; however, if the semantic model is in Import mode, no Lakehouse access is required after the data is imported (Dataset Permissions - Microsoft Docs, Direct Lake Deep Dive - Microsoft Blog).
Hope this helps.
Thank you.
9 Replies
Hi stellahe102 ,
Thank you so much for explaining your scenario !
OneLake Data Access roles give users access to specific tables or folders for reading data, whether through a shortcut or directly. However, when it comes to creating a semantic model, it works a bit differently. To build a semantic model from a lakehouse, users need permissions at the lakehouse level, not just table level access. That’s why, when you shared the whole lakehouse it worked but it also gave them visibility to all tables in that lakehouse. Right now, there is no way to restrict semantic model creation to just certain tables.
A common workaround is to create a separate lakehouse that only contains the Employee table, and give users build access there. That way, they can build their semantic model without seeing other data.
If like to see more granular permissions in the future, I would recommend posting your idea in the Fabric Ideas forum so the product team can take it into consideration. Hope this helps clarify things!
For more information,refer the below links:https://community.fabric.microsoft.com/t5/Data-Engineering/User-unable-to-access-semantic-model/m-p/4666363
https://powerbi.microsoft.com/en-in/blog/deep-dive-into-direct-lake-on-onelake-and-creating-direct-lake-semantic-models-in-power-bi-desktop/
Thank you.Regards,
Pallavi.Hi Pallavi. Thanks for the quick and helpful reply!
We appreciate you confirming that the build semantic model needs lakehouse-level access. We kind of feel that way, but it's good to get it confirmed. If you have any doc links around this, please share?
Context - our user case is a lakehouse without schema
Several follow-up questions:
1. It seems that "build report" access on the lakehouse is not enough. We need to give the "Read All SQL Endpoint data" option, too, so the user can create a new semantic model. Can you confirm this is true?
2. This workaround you mentioned - "A common workaround is to create a separate lakehouse that only contains the Employee table, and give users build access there. " does the separate lakehouse need to contain the materiazlied tables, or just shorcut is enough? if later then source lakehouse to the shortcut needs to be shared as well?
3. we are thinking another workaround to have someone in the user's workspace who has lakehouse level access to create the semantic model with 1 table, and then share the semantic model with the user and no lakehouse-level access is needed for the user, will this work from microsoft's infrastuctre perspective? we can test this out, but the access takes up to 2 hours to reflect for us making it hard to run test with the users.
Hi stellahe102 ,
Thanks for your detailed follow-up, your understanding is correct. To answer your questions: for Direct Lake semantic models, only Lakehouse Build permission is required to create a semantic model, users do not need the “Read All SQL Endpoint data” permission unless they are querying the SQL endpoint directly (Lakehouse Permissions - Microsoft Docs).
Regarding the second question, yes, you may create a shortcut in a separate Lakehouse that points to the Employee table. Just make sure users have Read permission on the source Lakehouse where the Employee table resides and Build permission on the new Lakehouse where they are creating the semantic model.
Finally, if someone else creates the semantic model and shares it, this also works. As per my knowledge, If the semantic model is in Direct Lake mode, users might still need Read permission on the Lakehouse at runtime to query the data; however, if the semantic model is in Import mode, no Lakehouse access is required after the data is imported (Dataset Permissions - Microsoft Docs, Direct Lake Deep Dive - Microsoft Blog).
Hope this helps.
Thank you.
Hi stellahe102 ,
Can you please confirm whether you have resolved issue. If yes, you are welcome to share your workaround and mark it as a solution so that other users can benefit as well. This will be helpful for other community members who have similar problems to solve it faster.
Thank you.
