Forum Discussion
Workspace Role
- 1 year ago
Hi sudip2607 ,
Great question — this is one of those areas where behavior and documentation can feel a bit out of sync.
You're right that the official documentation states that modifying Spark pool settings requires Admin role in the workspace. You can find that here:
🔗Microsoft LearnHowever, in practice, Contributor role can sometimes modify Spark pool settings if the workspace permissions are loosely scoped or inherited from broader Fabric-level permissions. This might explain why you were able to make changes with Contributor access.
That said, relying on Contributor for this task isn't guaranteed or recommended. Microsoft enforces role-based access control (RBAC) strictly in some environments, especially in enterprise tenants. So while it might work now, it could break later if policies are tightened.
To be safe and compliant with best practices:
- Use Admin role for Spark pool configuration.
- Use Contributor for pipeline, notebook, and dataset development.
Also, here's another helpful doc on Fabric roles and permissions:
🔗 Microsoft LearnLet me know if you want to test this behavior in a controlled setup or need help checking your workspace's permission inheritance.
If my response resolved your query, kindly mark it as the Accepted Solution to assist others. Additionally, I would be grateful for a 'Kudos' if you found my response helpful.
This response was assisted by AI for translation and formatting purposes.
Hi burakkaragoz
Thanks for your explanation. I'm convinced but wanted to learn more on this, how the loosly coupled setting works. By the way, your given links are not working for some reason.
Hi sudip2607 ,
You're right about the links - sorry about that! Let me explain the "loosely coupled" permissions thing because it's actually pretty interesting how Fabric handles this.
What I meant by "loosely scoped permissions":
In some Fabric environments, workspace permissions can inherit from higher-level settings or get influenced by:
- Tenant-level admin rights - If someone has broader Fabric admin permissions at the tenant level, those can sometimes override workspace-level restrictions
- Capacity admin permissions - Users with capacity admin rights might be able to modify Spark settings even with Contributor workspace role
- Legacy Power BI admin inheritance - Since Fabric evolved from Power BI, some permission behaviors carry over in unexpected ways
Here's what's probably happening in your case: Your Contributor user likely has one of these broader permissions without you realizing it. Check if they have:
- Any Fabric admin roles at the tenant level
- Capacity admin access on the capacity your workspace uses
- Power BI admin permissions that are carrying over
To test this properly: Create a test user with ONLY Contributor workspace access (no other admin rights anywhere) and see if they can still modify Spark settings. My guess is they won't be able to.
The documentation is correct about needing Admin role - but Fabric's permission inheritance can create these edge cases where it seems like Contributor works.
Does your Contributor user have any other admin rights you can think of?