We are excited to announce some big changes for Bitbucket Cloud invitations. Over the next week we will begin progressively rolling out a new, more intuitive way to invite new members to your workspace with increased management controls and transparency.
As part of Atlassian's cloud-first strategy, Bitbucket Cloud is investing in more and more enterprise capabilities to ensure a seamless experience for customers migrating from Server to Cloud. Empowering workspace admins to better manage the membership and permissions of large and growing teams is an important part of this strategy.
When we released our workspace collaboration model in 2020, it was the first step in this journey from favoring individual collaborators to favoring larger team and organization collaboration. This shift will become much more apparent in the coming months as we roll out new and improved audit logs, project permissions, and workspaces become an integral part of Atlassian organizations (including full Atlassian Access support).
As Bitbucket Cloud evolves, we want to make sure that adding and managing workspace membership via invitations evolves to keep pace. We are already seeing large teams relying more and more on groups to manage permissions rather than granting repository permissions to individual users. With project permissions we anticipate that more and more permissions will be defined for groups at the project level. Inviting individual users to a single repository will still be supported but is no longer the only or even the preferred way to add members and assign permissions in the workspace.
To support more group-first configurations, we are introducing Default Groups. All invited users going forward will be added to a group in the workspace designated as the 'default'. This default group can be an existing group or a new group – the choice is up to the workspace admin.
The addition of default groups more closely aligns Bitbucket Cloud with other Atlassian products where all invited users are added to a default group in the organization. Upon acceptance of an invitation, users will gain access to all resources available to that group. This allows users to quickly add teammates to all projects or repositories without requiring any configuration changes.
Additionally, workspace admins are afforded increased visibility into all of the users invited to the workspace from various locations based on this group's membership (i.e., users cannot be added to a single repository without also appearing in the default group).
The introduction of default groups means that invitations are no longer limited to repositories. Taking another cue from Jira and Confluence we are adding the ability for any user to invite teammates from the members page to join the workspace. These users will be added to the default group but will have no specific permissions on any project or repository not already granted to the group. This would allow admins to use the default group to vet all invited users before granting them any permissions.
Although we are opening up invitations to enable teams who want to grow quickly and make content available to all developers without constant configuration changes, we are also adding more workspace administration controls for customers who need tighter control of their content.
In addition to the increased visibility offered by default groups, workspace admins will now be able to restrict invitations in several ways. Workspace admins can now disable all end-users from sending invitations altogether, therefore only allowing workspace admins to add new members. Alternatively, workspace admins can define an email domain allowlist which prevents any workspace invitation from being sent to a user outside of those domains.
Note: Workspace admins are always able to invite any user to any group within the workspace.
We believe that all of these changes for invitations introduce much greater flexibility, as well as much greater control on how workspace admins can customize their experience in managing their workspace membership.