Forum Discussion
Self-Service via PowerBI - Permissions Issue
Hello all,
On these days I'm trying to expose semantic models to the user so they can build their owne reports on top of it. I don't want to give the access to the workspace, I only want they open Power Bi > OneLake > Choce semantic model and start workin on it.
To achieve this I basically allocate Read and Build permissions but looks like is not enough as I get the following error:
I notice is a permissions issue because if I set the permissions to "All permissions granted" then the users can work without problem. then I rollback the rights to the original ones but I notice that then the user can work without problem
So initialy user had:
- Read, Build
- Gets the error
- All permissions granted
- All good, no error
- Rollback again to Read and Build
- All good, no error
Is anyone facing the same issue?
Let me know if you need more context.
Hi uytut
I think that you're experiencing is essentially a permission propagation issue to the underlying data source behind the semantic model.
Here's what's actually happening.. When you grant only Read + Build on the semantic model, you're granting permissions on the semantic model item itself, but not on the underlying lakehouse/warehouse SQL analytics endpoint that the model connects to. The "Cannot load model" error with the database reference confirms this. Seems Power BI is trying to reach the underlying SQL endpoint and the user doesn't have access there.
When you temporarily grant "All permissions," Fabric propagates access downstream to the underlying data source. When you then rollback to Read + Build, the underlying permissions or cached tokens remain, which is why it keeps working after that. It's not that Read + Build suddenly became sufficient, it's that the underlying access was never revoked.
The actual fix is to grant the users ReadAll (or at minimum Read) permission on the underlying lakehouse or warehouse that backs your semantic model, specifically on its SQL analytics endpoint. You don't need to give them workspace access to do this. You can do it through:
- Go to the lakehouse/warehouse item directly
- Manage permissions → Share → grant ReadAll on the SQL analytics endpoint (not the lakehouse item itself, but the associated SQL endpoint)
- Alternatively, use the "Manage permissions" on the SQL analytics endpoint and add users with Read permission
Or programmatically.. through the Fabric REST API if you're doing this at scale.
If you're using DirectLake mode (default in Fabric), this is especially critical because DirectLake semantic models query the SQL analytics endpoint at runtime, unlike Import mode, there's no data copy sitting inside the model. The user's identity is passed through to the endpoint, so they need explicit access.
A cleaner enterprise-scale approach would be to create a security group, assign that group ReadAll on the SQL analytics endpoint, and Read + Build on the semantic model. That way onboarding new users is just adding them to the group.
Cost implication: none. ReadAll on the SQL analytics endpoint doesn't consume CU capacity on its own. The capacity cost comes from the actual queries the users run when building reports, which would happen regardless of how you grant the permission.
Happened with me before and this is how I fixed it 🙂
Let me know if this helps.
8 Replies
Hi uytut
I think that you're experiencing is essentially a permission propagation issue to the underlying data source behind the semantic model.
Here's what's actually happening.. When you grant only Read + Build on the semantic model, you're granting permissions on the semantic model item itself, but not on the underlying lakehouse/warehouse SQL analytics endpoint that the model connects to. The "Cannot load model" error with the database reference confirms this. Seems Power BI is trying to reach the underlying SQL endpoint and the user doesn't have access there.
When you temporarily grant "All permissions," Fabric propagates access downstream to the underlying data source. When you then rollback to Read + Build, the underlying permissions or cached tokens remain, which is why it keeps working after that. It's not that Read + Build suddenly became sufficient, it's that the underlying access was never revoked.
The actual fix is to grant the users ReadAll (or at minimum Read) permission on the underlying lakehouse or warehouse that backs your semantic model, specifically on its SQL analytics endpoint. You don't need to give them workspace access to do this. You can do it through:
- Go to the lakehouse/warehouse item directly
- Manage permissions → Share → grant ReadAll on the SQL analytics endpoint (not the lakehouse item itself, but the associated SQL endpoint)
- Alternatively, use the "Manage permissions" on the SQL analytics endpoint and add users with Read permission
Or programmatically.. through the Fabric REST API if you're doing this at scale.
If you're using DirectLake mode (default in Fabric), this is especially critical because DirectLake semantic models query the SQL analytics endpoint at runtime, unlike Import mode, there's no data copy sitting inside the model. The user's identity is passed through to the endpoint, so they need explicit access.
A cleaner enterprise-scale approach would be to create a security group, assign that group ReadAll on the SQL analytics endpoint, and Read + Build on the semantic model. That way onboarding new users is just adding them to the group.
Cost implication: none. ReadAll on the SQL analytics endpoint doesn't consume CU capacity on its own. The capacity cost comes from the actual queries the users run when building reports, which would happen regardless of how you grant the permission.
Happened with me before and this is how I fixed it 🙂
Let me know if this helps.
- svenchio
Super User
Thanks carlosmartins , kudos for this awesome and well estructure explanation! Your solution was correct and even though I'm not the posting user, this is a perfect solution based on my test of this issue... hope uytut agrees 🤞
Awesome svenchio! thanks for the feedback 🙏
Hello carlosmartins tayloramy ,
Well I'm a very simple approach using Excel files.
Around the carlosmartins comment I tryied to give access to all the files and folder in Sharepoint but the issue still.
Maybe I'm missing something... thank you for your comments.
Hi uytut
Oh that's different..
Would be an alternative to distribute your semantic model through a Power BI App instead of direct sharing? Apps handle their own permission layer and tend to avoid this issue entirely. Your users would find it under Apps instead of the OneLake data hub, but they can still build their own reports on top of it.
worth checking.. do you have Row-Level Security configured on the model? If RLS is active but the user isn't assigned to any role, the model will fail to load even with the right permissions. Granting "All permissions" temporarily bypasses RLS, which would explain why the rollback trick works.If none of this helps, I would suggest opening a support ticket with Microsoft so they'll address it properly.
Hope this helps!
Hi uytut
Thank you for reaching out to the Microsoft Fabric Forum Community.
tayloramy carlosmartins Thanks for the inputs.
I hope the information provided by users was helpful. please try those, If you still have issues, please open a support ticket as suggested by user Create a Fabric and Power BI Support Ticket - Power BI | Microsoft Learn.
Thanks.Hi uytut
Hope everything’s going smoothly on your end. I wanted to check if the issue got sorted. if you have any other issues please reach community.
