Forum Discussion
User with Contributor Role Unable to Checkout Branches or Create New Workspaces
Hi ifeanyi
-
Thank you for sharing your thoughtful workaround for managing least-privilege access in Microsoft Fabric.
-
We understand the current limitations around granular role-based permissions, especially compared to Synapse or Data Factory.
-
Using a dedicated collaboration workspace to isolate contributor access is a practical and effective solution.
In the meantime, if you're open to it, we recommend sharing your approach and suggestions on the Fabric Ideas - Microsoft Fabric Community It’s actively reviewed by the product team and helps influence future roadmap priorities.
Let us know if you’d like assistance with anything else or help streamlining your current setup further.
Thanks for being a part of Microsoft Fabric Community Forum.-
You're absolutely right—this limitation can be quite frustrating, especially when trying to maintain a least-privilege access model. It's not as straightforward as it is in Synapse or Data Factory.
To work around this, we’ve adopted a mitigation strategy by introducing an intermediary collaboration workspace. Here's how we approach it:
We start with a primary workspace, for example, contoso_wsp[Dev]. As an admin, I create a secondary workspace named contoso_collaboration_wsp. I then assign contributor users as admins to this collaboration workspace—not to the original one. This setup gives them the permissions needed to create their own development branches or workspaces (e.g., contoso_collaboration_wsp_contributor1, contoso_collaboration_wsp_contributor2, etc.).
Once their work is complete, I review and merge changes from these contributor workspaces back into the main contoso_wsp [Dev].
While it’s a bit of an overhead and certainly not ideal, this structure helps us maintain control over the dev environment while enabling contributor-level users to work independently.
That said, I’d be keen to hear how others are overcoming this challenge and whether there are any updates on how Microsoft Fabric plans to mature its support for DevOps/DataOps and CI/CD workflows.
Microsoft EmployeeHi ifeanyi ,
Thank you very much for your valuable contribution.
I’d like to better understand how your approach could fit into our setup. Currently, it seems that each user requires at least one dedicated workspace. If you have a collaboration workspace where multiple users are working simultaneously, only one branch can be active at a time.
I’m also curious to explore what happens when a developer is involved in multiple projects. It could become a maintenance challenge if we need to create a separate workspace for each developer and project combination.
I look forward to hearing your thoughts on this.
Hi hernandezpaulms ,
Thank you for raising these important considerations.You're absolutely right — there is a potential maintenance challenge when managing multiple workspaces, especially when developers are contributing across several projects. The intention behind our current approach is to allow contributors to branch out from the collaborative workspace, where all users have admin rights. This enables them to create their own isolated workspaces without affecting the main dev branch.
That said, we're still in the experimental phase and are hopeful that the native Git integration in Microsoft Fabric will soon evolve to better support the necessary functionality for contributor roles.
In parallel, we're also exploring an alternative approach where, as an admin of the main dev branch, I create dedicated branches for individual contributors (e.g., feature-x, feature-y, feature-z). Each contributor can then link their personal workspace to their respective feature branch, work independently, and later merge their changes back into the dev branch in a more controlled manner.
Hope this was helpful — I’d be keen to hear how others are approaching this as well.