Workspace Member Role - Can ADD but not EDIT Workspace Permissions

[chris_smith_fab]

I am a little frustrated by the Workspace role privileges.

I have setup my firm and Fabric to use a domain-centric model.

We have a central Data team having the ADMIN role on every workspace (manage name, endpoint, identity, spark, capacity)
and
We have our Domain Admins (business unit Power BI Developers) having the MEMBER role on every workspace they own.

The idea being that our developers cannot break anything important, but they can manage the security on the items they own.

But I don't understand why the MEMBER role allows them to ADD people/group at workspace-level permissions
But they cannot EDIT or REMOVE people/group at workspace-level permissions.

Do we know the thinking behind this, and if Microsoft plan any changes?
How do other teams set this up?

[v-ssriganesh]

Hello @chris_smith_fab,

We hope you're doing well. Could you please confirm whether your issue has been resolved or if you're still facing challenges? Your update will be valuable to the community and may assist others with similar concerns.

Thank you.

[v-ssriganesh]

Hi @chris_smith_fab,

Thank you for posting your query in the Microsoft Fabric Community Forum, and thanks to @stoic-harsh & @svenchio for sharing valuable insights.

Could you please confirm if your query has been resolved by the provided solutions? This would be helpful for other members who may encounter similar issues.

Thank you for being part of the Microsoft Fabric Community.

[stoic-harsh]

Hi @chris_smith_fab,

This is actually documented by Microsoft. Members can add other Members or anyone with lower permissions, but they can't remove anyone (including viewers). Link: https://learn.microsoft.com/en-us/fabric/fundamentals/roles-workspaces

So basically in your setup, Domain Admins (Workspace Members) will always need to escalate to your central Data team for any removal of workspace membership, even a Viewer they might have added themselves 5 minutes ago.

Your frustration is valid and honestly pretty common. These kind of asymmetries trip up a lot of teams including mine. For instance, OneLake Security behaviour doesn't always match what the docs describe (User's Identity mode being a notable example). These are just a few rough edges still present in the permission model.

Hope this clears it up!

Best,

Harshit

[svenchio · Accepted solution]

 Hi @chris_smith_fab  well, I can only my personal take as to why this works like this, the Member role can add users/groups to support collaboration, but editing or removing existing workspace permissions is restricted because those actions can impact broader governance and potentially lock out intended users/admins. I mena this prevent Members from unintentionally changing inherited or centrally managed access while still allowing them to onboard new contributors.... that being said, I agree that the granularity on permission on some (perhaps most) of fabric items has a long way to go! Just to put in perspective, I've been waiting for deployment pipelines (exists since the begining) to have other permission other than admin, and has not been implemented yet 😅👇  

Hope you can figure it out a smart way or even compromise on the security to have everyone on your company colaborating! If you find this reflextion useful, a thumbs up would be nice, best of lucks