Atlassian Confluence User Management Guide

• Model type: hybrid
• Description: Three-tier model: (1) Global permissions (Confluence-wide, set by Confluence admins) control who can log in and create spaces. (2) Space permissions (per-space, set by space admins) control what users and groups can do within each space including view, add, edit, delete, restrict, export, and administer. (3) Content-level restrictions (per-page or blog post, set by editors) further restrict viewing or editing of individual content items. Permissions are additive across groups. A role-based access control model with four default roles (Admin, Manager, Collaborator, Viewer) and up to 10 custom roles is rolling out in beta as of late 2025.
• Custom roles: Yes
• Custom roles plan: Standard, Premium, and Enterprise (RBAC feature in beta as of late 2025; only Confluence product admins can create, edit, or delete custom roles)
• Granularity: Global (site-wide), space-level (per space, per user or group), and content-level (per page or blog post). Space permissions include: View, Add pages/blogs/comments/attachments, Edit, Delete, Archive, Restrict content, Export space, Administer space.

1. Go to admin.atlassian.com.
2. Select your organization if you have more than one.
3. Select Directory, then select Users.
4. Select Invite users.
5. Enter the email addresses for the users you want to invite (multiple addresses separated by comma or space).
6. Select roles for the apps that they need access to (e.g., assign Confluence User role).
7. Optionally search for and add users to specific groups.
8. Personalize the invitation message or choose not to send one.
9. Select Invite users to send the invitation.

Required fields: Email address, App role selection (e.g., Confluence User or Guest)

Watch out for:

• Deactivated or disabled accounts cannot be invited; the account must be reactivated first.
• If a user already has an Atlassian account under a different organization, they will receive an invite to join the new site but their account is not managed until domain is claimed.
• Adding a user to a site does not automatically grant them access to any space; space permissions must be configured separately.
• On the Free plan, the site is limited to 10 users total; inviting beyond this limit requires upgrading.
• Users invited but not yet accepted still count toward the pending invite limit and may consume a seat depending on billing cycle timing.

• Can delete users: Yes
• Delete/deactivate behavior: Atlassian Cloud supports both deactivation (suspending access while retaining account and content) and permanent deletion of managed accounts. Deactivation is reversible; deletion is permanent after a 14-day grace period during which the account can be restored. Non-managed accounts (unverified domain) can only be removed from a site, not deleted by the org admin. Data Center supports disabling (reversible) or deleting users, with content retained in both cases.

1. Go to admin.atlassian.com.
2. Select your organization.
3. Select Directory, then select Managed accounts.
4. Find the user and select their name to open their profile.
5. Select Deactivate account.
6. Confirm the deactivation.

Watch out for:

• Only Org Admins can deactivate managed accounts; Site Admins cannot perform this action for managed accounts.
• Deactivating a user does not remove them from groups; if reactivated, they regain access based on existing group memberships.
• Non-managed accounts (users whose email domain is not claimed) can only be removed from a site, not deactivated or deleted by the org admin.
• Permanent deletion of a managed account has a 14-day grace period; after that, the account and all associated personal data are permanently removed.
• If a user is the sole space admin of a space, deactivating them leaves the space without an admin; a Confluence admin must recover permissions.
• SCIM-provisioned users deactivated via IdP are suspended in Atlassian but not permanently deleted; deletion must be done separately in admin.atlassian.com if required.

• Where to check usage: admin.atlassian.com > [Organization] > Billing > [Select Confluence] to view current user count and seat usage; or admin.atlassian.com > Directory > Users to review active user list.
• How to identify unused seats: Navigate to admin.atlassian.com > Directory > Users and filter by Last active date to identify users who have not logged in recently. Atlassian does not provide a built-in automated inactive user report on Standard; Atlassian Guard Premium adds user activity reporting and inactive user detection.
• Billing notes: Billing is based on the number of active users at the end of each billing cycle. Adding users mid-cycle results in prorated charges. Removing or deactivating users frees seats at the next billing cycle. A 5% price increase for Standard and 7.5% for Premium and Enterprise is effective October 2025. Enterprise plan includes Atlassian Guard Standard at no additional cost. Atlassian Guard Standard is $4 per user per month when purchased separately and is required for SCIM provisioning on Standard and Premium plans.

Without automated provisioning, every app in your stack requires manual invite-and-permission steps each time a user joins, moves teams, or leaves. In Confluence, adding a user involves inviting via admin.atlassian.com, assigning a product role, and then separately configuring space permissions - none of which are linked by default.

Offboarding carries the highest risk. Only Org Admins can deactivate managed accounts; Site Admins cannot. If a departing user is the sole Space Admin of any space, deactivation leaves that space unmanaged until a Confluence admin manually recovers permissions.

SCIM-based deactivation suspends the account but does not delete it - a separate deletion step in admin.atlassian.com is required to fully remove personal data.

License hygiene is also manual by default. Confluence Standard does not include automated inactive user detection; identifying unused seats requires filtering the user list by last active date in admin.atlassian.com. Atlassian Guard Premium adds inactive user reporting, but that requires an additional subscription on top of Standard or Premium plans.

The most consistent complaint across the Atlassian community is the cost of Atlassian Guard. SCIM provisioning - a baseline expectation for enterprise identity management - requires a Guard Standard subscription ($4/user/month) on Standard and Premium plans.

Users on those tiers frequently report expecting SCIM to be included.

API key expiration is a recurring operational pain point. As of January 2025, API tokens have a hard 1-year maximum lifetime.

Tokens that expire silently break automations and integrations without warning, and there is no native alerting for upcoming expiration.

Two permission-model issues surface repeatedly: the additive permission model makes it impossible to restrict a specific user if they belong to a group with broader access, and confusion between Org Admin and Site Admin roles causes admins to be unable to deactivate users because they hold only Site Admin access.

Bulk user creation via CSV is also not supported in Cloud - provisioning at scale requires IdP integration or repeated manual invites.

Common complaints:

• Additional Atlassian Guard subscription cost required for SCIM provisioning on Standard and Premium plans is a common complaint; users expect SCIM to be included.
• API key expiration (1-year maximum as of January 2025) causes unexpected automation and integration failures when keys expire silently.
• Confusion between Org Admin and Site Admin roles leads to admins being unable to deactivate users because they only have Site Admin and not Org Admin access.
• No native CSV import for bulk user creation in Cloud; bulk provisioning requires IdP integration or manual invites.
• Permissions are additive and cannot be negated at the individual level if a user is in a group with broader permissions, making it difficult to restrict specific users.
• Deactivating a user via SCIM (IdP) suspends but does not delete the account; admins must separately delete in admin.atlassian.com to fully remove personal data.
• Guest user limitations (one space only, no mobile app) are frequently cited as too restrictive for external collaboration use cases.
• The transition from legacy space permission tables to the new RBAC role model has caused confusion about which model applies to existing spaces.
• Google Cloud vs. Google Workspace confusion when setting up SSO or SCIM provisioning.
• Users removed from a site but whose email domain is not claimed cannot be fully deactivated or deleted by the org admin.

Manual management is viable for small, stable teams on the Free plan (up to 10 users) or Standard plan where headcount and org structure change infrequently.

The three-tier permission model is powerful but requires deliberate setup - space permissions must be configured separately from product access, and group membership does not substitute for explicit space-level grants. For every app in a growing SaaS stack, Confluence is rarely the only place access needs to be adjusted when someone joins or leaves.

The decision to invest in automated provisioning typically hinges on three factors: team size, offboarding risk tolerance, and whether you already pay for Atlassian Guard.

If your organization manages Confluence alongside Jira or other Atlassian products, Guard Standard ($4/user/month) unlocks SCIM across the entire Atlassian directory - not just Confluence - which changes the per-app cost calculus.

Organizations with high contractor or guest-user volume should also account for guest lifecycle management. Suspended guests are removed from their assigned space and must be manually reassigned on restoration. Managed account guests may count toward Guard billing, so guest sprawl has direct cost implications.

Bottom line

Confluence's permission model is capable but layered: global permissions, space permissions, and content restrictions each require separate configuration, and group-based access is additive with no individual-level override.

Manual administration is workable for small or slow-changing teams, but offboarding risk scales quickly - only Org Admins can deactivate managed accounts, SCIM deactivation does not delete accounts, and sole-space-admin situations create access gaps that require manual recovery.

The additional cost of Atlassian Guard for SCIM on Standard and Premium plans is the most common friction point teams hit when trying to automate provisioning, and the 1-year API token expiration adds ongoing operational overhead for any integration that relies on API authentication.