Atlassian Bitbucket User Management Guide

• Model type: role-based
• Description: Bitbucket Cloud uses a hierarchical, role-based permission model with four scopes: workspace, project, repository, and branch. Permissions are inherited downward: workspace admin permissions propagate to all projects and repositories. Project permissions apply to all repositories within that project. Repository-level permissions can extend or restrict access beyond project-level grants. Permissions can be assigned to individual users or user groups. No custom roles exist; only the predefined levels (Admin, Create, Write, Read) are available at each scope.
• Custom roles: No
• Custom roles plan: Not documented
• Granularity: Four predefined levels per scope (workspace, project, repository, branch). Branch permissions provide an additional layer to restrict push/merge actions on specific branches.

1. Log in to bitbucket.org and navigate to the target workspace.
2. Select the Settings cog (top navigation bar) > Workspace settings.
3. Under Access Management, select User groups.
4. Select the group to which you want to add the user, then select Add members.
5. Enter the user's name or email address. If the user does not have a Bitbucket account, they will receive an email to create one.
6. Select an access level (workspace permission) from the dropdown, then select Confirm.
7. Optionally, grant the user or their group access to specific projects via Project settings > Project permissions > Add users or groups.
8. Optionally, grant direct repository access via Repository settings > User and group access > Add members.

Required fields: User email address or Bitbucket username, Target user group (or direct repository/project assignment), Permission level (Read, Write, Create, or Admin)

Watch out for:

• In Bitbucket Cloud, admins cannot create a Bitbucket account on behalf of a user; the user must create their own account and accept the invitation.
• Newer workspaces linked to an Atlassian organization manage users via admin.atlassian.com, not bitbucket.org. The path differs depending on workspace age.
• All Bitbucket workspaces must be linked to an Atlassian organization by March 15, 2026, or workspace functionality will be impacted.
• Adding a user to any workspace group makes them a billable workspace member, even if the group has no repository or project permissions.
• On the Free plan, exceeding 5 workspace members causes all private repositories to become read-only for non-admins until the plan is upgraded or users are removed.
• Invited users who have not yet accepted their invitation still appear as pending and do not consume a seat until they accept.

• Can delete users: Yes
• Delete/deactivate behavior: Two distinct actions are available for org-managed accounts. Deactivation (via admin.atlassian.com by an Organization Admin): the user immediately loses access to Bitbucket and all Atlassian services; billing stops; personal data is retained and the account can be reactivated at any time. Deletion (via admin.atlassian.com by an Organization Admin): the user immediately loses access; billing stops; personal data is permanently deleted from all Atlassian account services and the account cannot be reactivated. An org admin can delete a previously deactivated account. For workspace removal without org-level account deletion, a workspace admin can remove the user from the workspace entirely via Workspace Settings > User Directory, which revokes all repository access and removes them from billing without deleting their Atlassian account.

1. For org-managed accounts (deactivate without deleting): Go to admin.atlassian.com > Directory > Users > select the user > deactivate the account. The user loses access immediately and billing stops.
2. For workspace removal only (legacy bitbucket.org-managed workspaces): Go to bitbucket.org > Workspace settings > User Directory > locate the user > select '...' in the Actions column > select Remove. This permanently removes the user from the workspace and revokes access to all repositories.
3. For workspace removal only (Atlassian Admin-managed workspaces): Go to bitbucket.org > Settings cog > User management (redirects to admin.atlassian.com) > locate the user > remove their Bitbucket product access.
4. Verify the user no longer appears under 'Users on Plan' in Workspace Settings > User Directory to confirm billing removal.

Watch out for:

• Removing a user from a project or repository does not remove them from the workspace; they remain billable until fully removed from the workspace.
• A workspace admin cannot remove a user whose personal workspace is the workspace being managed (pre-February 2023 personal workspaces). The user must delete their own account or Atlassian support must be engaged.
• Once an Atlassian account is permanently deleted, it cannot be restored. There is a 14-day grace period during which the deletion can be cancelled.
• Inactive users who have direct repository access (not only group access) will still appear in the workspace even after being removed from all groups; their direct repository permissions must also be revoked.
• Deleting a user account that owns a personal workspace causes that workspace and all its repositories to be permanently deleted.

• Where to check usage: Workspace settings > User Directory > filter by 'Users on Plan' dropdown to see all billable members. For org-linked workspaces, also check admin.atlassian.com > Billing.
• How to identify unused seats: Navigate to Workspace Settings > User Directory and review the list of workspace members. Filter by 'Users on Plan'. For inactive users, use the Bitbucket REST API endpoint GET /2.0/workspaces/{workspace}/members to retrieve member list and cross-reference with last activity. No native last-login filter exists in the Bitbucket Cloud UI; API or third-party scripts are required to identify inactive users.
• Billing notes: A billable user is any user who is a member of the workspace, regardless of whether they have access to any private repositories or projects. Removing a user from a project or repository but leaving them in a workspace group still counts them as billable. Additional Pipelines build minutes cost $10 per 1,000 minutes. Additional Git LFS storage costs $10 per 100 GB/month. All new Bitbucket Cloud purchases are billed on the new Atlassian billing platform as of September 10, 2025. Existing subscriptions are being migrated starting October 6, 2025. SCIM provisioning requires a separate Atlassian Guard subscription (not included in any Bitbucket plan tier).

Bitbucket's billing model has a sharp edge: any user added to a workspace group becomes a billable member, even if that group has no repository or project permissions assigned. Removing a user from a project or repository does not stop billing - a separate workspace-level removal is required.

On the Free plan, exceeding 5 workspace members causes all private repositories to become read-only for non-admins until the plan is upgraded or users are removed.

SCIM provisioning requires a separate Atlassian Guard subscription on top of any Bitbucket plan tier, and Guard is billed per managed user across the entire Atlassian organization - not per product.

Identifying inactive users requires either the Bitbucket REST API or third-party scripts; no native last-login filter exists in the UI. Admins should audit the User Directory regularly using the 'Users on Plan' filter to catch orphaned seats.

The most consistent friction point reported by admins is the absence of group sync via SCIM: only user accounts can be provisioned automatically, so repository and project permissions must still be assigned manually after every new hire is onboarded.

This creates a persistent gap between identity provider state and actual Bitbucket access.

A second recurring issue is the billing trap around project and repository removal. Admins frequently discover that removing a user from a repo leaves them on the billing count, requiring a second action at the workspace level.

Additional pain points include: SCIM API keys expiring annually (enforced since January 2025) requiring mandatory rotation; Workspace Admins being unable to remove users whose personal workspace predates February 2023 without Atlassian support involvement; and Guard costs applying to all managed users org-wide even when only a subset use SCIM.

Common complaints:

• No native group sync for Bitbucket via SCIM - only user accounts can be provisioned; repository and project permissions must still be assigned manually after SCIM provisioning.
• Removing a user from a project or repository does not remove them from the workspace billing count; admins must perform a separate workspace-level removal to stop billing.
• Workspace admins cannot remove users whose personal workspace is the managed workspace (pre-February 2023 accounts), requiring workarounds or Atlassian support involvement.
• SCIM provisioning requires an additional Atlassian Guard subscription on top of the existing Bitbucket plan, adding significant per-user cost.
• Atlassian Guard is billed per managed user across the entire Atlassian organization, not per product, meaning teams pay Guard costs for all users even if only some use SCIM.
• SCIM API keys expire after one year (as of January 2025), requiring mandatory annual rotation.
• Older workspaces (pre-February 2023) have user management at bitbucket.org while newer workspaces use admin.atlassian.com, creating inconsistent admin experiences.
• All Bitbucket workspaces must be linked to an Atlassian organization by March 15, 2026, or risk losing workspace functionality including Forge app installation.
• No built-in UI filter for last login or inactivity date in Bitbucket Cloud; identifying unused seats requires REST API queries or third-party tooling.
• Workspace admins who are not Org Admins cannot access admin.atlassian.com for user management in org-linked workspaces without being granted the User Access Admin role separately.

Manual management is viable for small, stable teams on the Free or Standard plan where the 5-seat ceiling and infrequent user changes make automation overhead unjustifiable. The two-console split (bitbucket.org vs. admin.atlassian.com) adds friction but is navigable once the workspace-to-org link is established.

For teams with regular onboarding and offboarding, the absence of group sync is the critical constraint. SCIM provisions Atlassian accounts but does not assign Bitbucket repository permissions - meaning every provisioned user still requires a manual permission step inside Bitbucket.

Teams should weigh the Guard subscription cost against the ongoing manual effort before committing to SCIM.

Organizations already paying for Atlassian Guard for Jira or Confluence get Bitbucket SCIM user provisioning at no additional Guard cost, since Guard is billed per managed user across the org. That changes the calculus significantly for multi-product Atlassian shops.

Bottom line

Bitbucket Cloud's permission model is well-structured but operationally demanding at scale. The billing model punishes incomplete offboarding, the lack of SCIM group sync forces manual permission assignment after every provisioning event, and the dual-console experience adds cognitive load for admins managing mixed-vintage workspaces.

Teams that already pay for Atlassian Guard across other products get the most value from SCIM here; teams evaluating Guard solely for Bitbucket should carefully model the per-user org-wide cost against the time saved on user provisioning alone.