User with Contributor Role Unable to Checkout Branches or Create New Workspaces

[ifeanyi]

I recently created a Microsoft Fabric workspace and added a user with the Contributor role. The workspace is connected to an Azure DevOps repository. However, we noticed that the user is unable to perform certain actions, specifically:

1. Checkout a branch

2. Branch out to a new workspace

These options remain disabled for the user as shown in the image below.

Interestingly, when I change the user’s role from Contributor to Admin, the options become available, and the user can perform the actions without any issues.

Has anyone encountered a similar situation? Is this expected behavior for the Contributor role, or could there be a configuration issue? Additionally, could the integration with the Azure DevOps repository be impacting these permissions?

Any insights or suggestions would be greatly appreciated.

Thank you in advance!

[hernandezpaulms]

I'm curious about your strategies for overcoming this limitation. Personally, I find it quite frustrating that a Workspace member or contributor cannot create a new branch—something that's possible in Synapse or Data Factory workspaces. Assigning the Workspace Admin role feels too elevated and doesn't align with a least privilege approach.

[ifeanyi]

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.

[hernandezpaulms]

Hi @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.

[ifeanyi]

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.

[v-aatheeque · Accepted solution]

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.

[Yannick_Imec]

We are seeing similar things all of the sudden since a week or so.

No clear update/change can be found on any summary by Microsoft about roles, so no clue what happened.

We tested previously with contributor role and commiting and updating worked fine, now it doesn't anymore.
We had to change the users to admins, this cannot be the way to go.

Looking forward to what real solution will be provided here...

[AdityaSQLFabric]

Please verify below link from Microsoft to get more insights.

https://learn.microsoft.com/en-us/fabric/cicd/git-integration/git-integration-process?tabs=Azure%2Ca...

[ifeanyi]

Thank you for sharing the link to the Microsoft documentation. I have reviewed the resource, and it confirms that workspace roles such as Admin, Member, and Contributor should have the ability to "Branch out to new workspace."

Current Setup:

• As the Fabric Admin, I have enabled the organization-wide setting to allow workspace creation for all users.

Issue Observed:

1. Users with the Contributor role do not have access to the "Branch out to new workspace" option (it remains disabled).

2. When I upgrade the user’s role to Member, the option becomes enabled, but attempting to use it results in an error.

3. The feature functions only when the user is assigned the Admin role, which is not ideal from a security and governance perspective.

Request for Further Assistance:

• Are there additional prerequisites or configurations required beyond the documented settings?

• Could this be a potential issue with role-based permissions or a system limitation?

I would appreciate any further insights or troubleshooting steps to resolve this discrepancy. Thank you in advance for your support!

[AdityaSQLFabric]

Verified from my end and I see below documentation from Microsoft, please check below and try to troubleshoot. 

https://learn.microsoft.com/en-us/fabric/cicd/troubleshoot-cicd#branching-out-i-dont-see-the-branch-...

https://learn.microsoft.com/en-us/fabric/cicd/git-integration/manage-branches?tabs=azure-devops#scen...

https://learn.microsoft.com/en-us/fabric/cicd/git-integration/git-integration-process?tabs=Azure%2Cg...

https://learn.microsoft.com/en-us/fabric/cicd/git-integration/conflict-resolution

[v-aatheeque]

Hi @ifeanyi ,

Did @AdityaSQLFabric  response resolve your issue?

If yes, please consider marking the helpful reply as the accepted solution. This helps other community members with similar questions find answers more easily.

Thank you for being a valued member of the Microsoft Fabric Community Forum!

[ifeanyi]

Hi @v-aatheeque ,

Thanks for following up. @AdityaSQLFabric response provided useful insights. 

However, some other user have also reported experiencing similar issues, indicating a gap between expected functionality and actual implementation. This concern needs to be raised with the Microsoft Fabric team for further clarification.

You can also check out this discussion:

https://www.skool.com/microsoft-fabric/new-video-3-of-the-dp-700-series-just-launched-on-cicd?p=0d0d... 

[v-aatheeque]

Hi @ifeanyi ,

Thanks for highlighting the issue. I also suggest posting it in the Ideas platform so that Microsoft may consider implementing it in the future.
https://ideas.fabric.microsoft.com/ideas/search-ideas/

Feedback submitted through these channels is frequently reviewed by the product teams and can contribute to meaningful improvements.

 If our response addressed by the community member for  your querys, please mark it as Accept Answer and click Yes if you found it helpful.

Thank you for being a part of the Microsoft Fabric Community Forum!
 

[ifeanyi]

I am the administrator of a Microsoft Fabric workspace connected to an Azure DevOps repository, and I have encountered an issue with user permissions. Specifically, when adding a user with Contributor access, they are unable to perform the following actions:

• Check out a branch
• Create a new branch from the workspace

These options remain disabled for the user, as shown in the attached image.

However, when I update their role to Member, the options become enabled, allowing them to create a branch. Unfortunately, an error occurs during the process (details in the attached image).

When I further upgrade their role to Admin, they can successfully check out and create a new branch without any issues.

I want to adhere to the principle of least privilege, meaning I do not want users to have Admin access unless absolutely necessary. Ideally, I would like them to perform these actions as Contributors. Could you please confirm whether this is expected behavior or if there is a configuration setting that needs adjustment?

Your guidance on resolving this would be greatly appreciated.

Thank you in advance for your support!

[nilendraFabric]

Hello @ifeanyi 

This is expected behaviour. 

The Contributor role in Microsoft Fabric allows users to view and modify content within a workspace but does not include permissions for managing workspace settings or advanced configurations like Git integration. These capabilities are typically reserved for Members and Admins

Members can perform tasks such as sharing content, adding users with lower permissions, and managing some workspace settings, while Admins have full control over workspace management, including permissions and configurations

https://learn.microsoft.com/en-us/fabric/security/permission-model

Please accept this answer and give kudos if this is helpful 

[ifeanyi]

Hi @nilendraFabric ,

Thank you for your response. I understand that Contributors have limited permissions compared to Members and Admins. However, the Microsoft Fabric Git integration documentation suggests Contributors should be able to checkout branches and create workspaces as part of the Git workflow.

Could there be additional settings or restrictions causing this, or is the documentation outdated? I’d appreciate further clarification.

Thanks again!

[nilendraFabric]

Hello @ifeanyi 

Contributor role can pull updates from Git (“Update from Git”) and push or commit changes (“Commit workspace changes to Git”) only if they have full WRITE rights on all items that need modification. This means:
• The user must be granted the Contributor role in the workspace.
• Their corresponding Git repository permissions should be set to allow both reading (Read=Allow) and contributing (Contribute=Allow) changes.
• Additionally, branch policies must be configured to permit direct commits. If the branch has requirements like pull requests or other controls, those rules must be respected, and direct commits might not be allowed.

see if this is all done and then test it. 

[ifeanyi]

Hi @nilendraFabric ,

Thank you for the detailed explanation. To clarify, I have already assigned the user the Contributor role in the workspace and granted them Project Contributor access to the project from the Azure DevOps Git repository.

I assumed that (Read=Allow) and (Contribute=Allow) permissions would be applied automatically, as this was the case in previous setups where users with the Contributor role in the workspace could perform Git operations without additional configuration.

However, I reviewed the Azure DevOps Git repository settings under Project Settings --> Permissions --> Contributors and did not find the explicit (Read=Allow) option as described in the image below.

Could you please confirm if these permissions are managed elsewhere or if there’s an additional step I might be missing?

Thank you for your support!

[v-aatheeque]

Hi @ifeanyi ,

@nilendraFabric  Thanks for your prompt response, In addition to that you can refer below link related to Git repositoty permissions.

Doc : https://learn.microsoft.com/en-us/azure/devops/repos/git/set-git-repository-permissions?view=azure-d...

If this post helps then please consider Accept it as the solution to help the other members find it more quickly.
 
Should you have any further questions, feel free to reach out.
Thank you for being a part of the Microsoft Fabric Community Forum!
 

[Yannick_Imec]

We are seeing simalar issues all of the sudden since a week or so.
No changes have been done to the repository on devops, so the permissions are still the same and work, if the user has admin role on the workspace.
However before a week ago, the user was contributor and it worked as well, so something has changed but apparently nobody knows...