Summary and recommendation
Atlassian user management can be run manually, but complexity usually increases with role models, licensing gates, and offboarding dependencies. This guide gives the exact mechanics and where automation has the biggest impact.
Atlassian's admin layer sits at admin.atlassian.com and spans four distinct platform roles: Organization Admin, Site Admin, User Access Admin, and App Admin.
Each role carries hard boundaries - for example, Site Admins in the centralized user management experience can approve access requests but cannot remove the users they approved without also holding the User Access Admin role.
Product access and in-app permissions are managed separately. Platform roles live in Atlassian Administration; granular permissions (Jira project schemes, Confluence space permissions) are configured inside each product. There are no custom platform-level admin roles - the four roles are fixed.
SCIM provisioning and SSO require an Atlassian Guard Standard subscription (or Enterprise Cloud, which includes Guard Standard). Guard Standard is an add-on billed per unique managed user across the org, counted once regardless of how many products that user accesses.
Quick facts
| Admin console path | admin.atlassian.com > [Select Organization] > Directory > Users |
| Admin console URL | Official docs |
| SCIM available | Yes |
| SCIM tier required | Atlassian Guard subscription |
| SSO prerequisite | Yes |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Organization Admin | Highest-level admin. Manages all users, groups, apps, security, authentication policies, and billing across all sites in the organization. Can add/remove other org admins, site admins, and user access admins. Automatically holds site admin role on all sites. | Cannot remove their own org admin role; requires another org admin to do so. Cannot be the sole org admin and remove themselves without first assigning another. | Any paid plan (role exists on Free plans but full security controls require Guard Standard or higher) | Billable as a product user if assigned product access; the org admin role itself does not add a separate seat cost | Granting org admin automatically grants site admin on all sites and cannot be scoped to a single site. Only org admins can manage other org admins. |
| Site Admin | Manages users, groups, apps, and settings for a specific site. Can approve/deny product access requests, add new products and Marketplace apps, track storage, and has limited billing access. | In centralized user management, Site Admins can approve access requests but cannot remove users (no permission to modify users). Cannot export or view managed account users - only org admins can. | Any plan | Non-billable as a site admin role alone; must be separately assigned product access to consume a license seat | In centralized user management, Site Admin cannot remove users they approved. Must be combined with User Access Admin role ('Dual permission') to manage user access. |
| User Access Admin | Manages user access for specific apps/products: can invite users, change product access, alter group memberships, and make other users product admins. Can view users in the organization at admin.atlassian.com. | Cannot manage org-level security settings, authentication policies, or billing. Cannot manage passwords or MFA (org admin only). | Any plan (centralized user management experience only) | Billable only if assigned product access | Role only exists in the centralized user management experience, not the original experience. |
| App Admin (e.g., Jira Admin) | Administers settings for a specific app (e.g., Jira project schemes, workflows, permission schemes). Added to the default app-admins group (e.g., jira-admins- |
Cannot access Atlassian Administration (admin.atlassian.com). Cannot invite new users to the organization - must contact an org admin. | Any plan | Billable as a product user | App admin role does not automatically grant product access; product access must be assigned separately. For Jira, all Jira apps share the same admin console, so the role is granted under 'Jira Administration'. |
| Regular User (Product User) | Can log in to assigned Atlassian apps and use their features per project/space permission schemes. In Jira: can create, edit, comment on, and delete work items; use boards; create dashboards. | Cannot access admin.atlassian.com. Cannot manage other users, billing, or org settings. | Any plan | Billable; counts toward the app license seat count | Users are counted toward billing even if they never log in after being invited. Inviting a user immediately starts billing on monthly plans. |
Permission model
- Model type: role-based
- Description: Atlassian Cloud uses a layered role-based model with four platform admin roles (org admin, site admin, user access admin, app admin) managed in Atlassian Administration, plus in-app permission schemes (project permission schemes in Jira, space permissions in Confluence) managed within each product. Groups are the primary mechanism for assigning product access and in-app permissions at scale. The centralized user management experience (newer) separates user management from site administration, while the original experience conflates them.
- Custom roles: No
- Custom roles plan: Not documented
- Granularity: Platform-level roles are fixed (org admin, site admin, user access admin, app admin). In-app permissions are highly granular via project permission schemes in Jira (e.g., Create Issues, Edit Issues, Assign Issues per project role) and space permissions in Confluence. No custom platform-level admin roles can be created.
How to add users
- Go to admin.atlassian.com and select your organization.
- Navigate to Directory > Users (centralized experience) or go to the site-level Users page (original experience).
- Select 'Invite users'.
- Enter one or more email addresses separated by commas or spaces.
- Select the product(s) the user should have access to from the Product roles dropdown.
- Optionally assign group memberships and a product admin role.
- Optionally personalize the invitation email.
- Click 'Invite' - the user receives an email invitation and their status becomes Active once they accept.
Required fields: Email address
Watch out for:
- Users are counted toward billing immediately upon invitation, even before they accept or log in.
- The invite UI auto-selects all products by default in the new user access settings experience; admins must manually deselect products they want to restrict.
- App admins can only add existing site users to projects; they cannot invite new users to the organization - only org admins or user access admins can.
- Invitation emails expire after 7 days (Data Center) or can be suppressed/blocked by user email preferences; use 'Resend invitation' if not received.
- If a user's domain is claimed by another organization, inviting them may require the user to be a managed account under that org first.
- Deactivated managed accounts cannot be re-invited until reactivated by an org admin.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | No | No native CSV user-import exists in Atlassian Cloud admin UI. Bulk invite is done by entering multiple comma/space-separated email addresses in the Invite users form, or via the REST API. CSV import for users is available in Atlassian Crowd (self-managed) and via third-party Marketplace apps. |
| Domain whitelisting | Yes | Automatic domain-based user add |
| IdP provisioning | Yes | Atlassian Guard Standard (formerly Atlassian Access) - $3–4/user/month add-on, or included with Enterprise Cloud plan |
How to remove or deactivate users
- Can delete users: Yes
- Delete/deactivate behavior: Three distinct actions exist: (1) Suspend access - temporarily removes access to a specific site; user retains group memberships and roles, billing stops, access can be restored. (2) Remove user - removes the user from the organization or site entirely; billing stops; roles and group memberships are lost and must be reassigned if re-invited; does not delete the Atlassian account. (3) Delete managed account - permanently deletes the account and personal data after a 14-day grace period; only possible for accounts whose domain is claimed and managed by the organization (managed accounts). Non-managed accounts can only be deleted by the account holder themselves.
- For managed accounts - deactivate: Go to admin.atlassian.com > select organization > Directory > Managed accounts.
- Select the checkboxes next to the accounts to deactivate.
- Select 'Deactivate' above the table and follow the prompts.
- For suspend (non-managed or site-level): Go to admin.atlassian.com > select site > Users page.
- Find the user, select the more actions menu (•••).
- Select 'Suspend access'.
- For remove (centralized experience): Go to admin.atlassian.com > select organization > Directory > Users.
- Find the user, select the more actions menu (•••).
- Select 'Remove user'.
| Data impact | Behavior |
|---|---|
| Owned records | Issues, pages, comments, and other content created by the user remain in place and are not deleted when a user is removed or suspended. If the account is permanently deleted, the user appears as 'Former user' in Jira and personal data is erased from Atlassian account services, but content (issues, comments) remains attributed to 'Former user'. |
| Shared content | Shared filters and dashboards owned by a deleted user are deleted even if shared with others. Personal data embedded in issue fields or free-form text remains until the project or site is deleted. |
| Integrations | Deleting an Atlassian account does not delete associated Jira Align, Halp, or Opsgenie accounts - those must be handled separately. If SCIM provisioning is active, the user must be removed from the IdP first; otherwise the account may be automatically recreated. |
| License freed | Billing stops immediately upon suspension or removal. For monthly plans, the seat is freed for the next billing cycle. For maximum-quantity billing, removing a user mid-cycle does not reduce the current month's bill but frees a seat for reallocation; the lower count applies at the next billing period. |
Watch out for:
- You cannot remove or deactivate a user who is the sole org admin; another org admin must be assigned first.
- To remove a user who is both org admin and site admin, the org admin role must be removed first before the site admin role can be removed.
- Removing a user from one site does not remove them from other sites in the organization.
- Only managed accounts (domain claimed by the org) can be permanently deleted by an admin. Non-managed accounts can only be self-deleted by the user.
- If SCIM provisioning is active, deleting the account in Atlassian without first removing the user from the IdP will cause the account to be automatically recreated on the next sync.
- Accounts stuck in a 'for deletion' state due to SCIM conflicts require unlinking the SCIM record before deletion can proceed.
- After permanent deletion, the email address is not immediately available for reuse; admins should update the account email to a placeholder before deletion if the address needs to be reassigned.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Product User (e.g., Jira Software, Confluence, JSM Agent) | Full access to the assigned Atlassian cloud product. Counts toward the product's billable user count. Free plan supports up to 10 users (3 agents for JSM). | Varies by product and plan tier (Free, Standard, Premium, Enterprise). Monthly: per-user pricing. Annual: tiered pricing based on user count brackets. See atlassian.com/software/jira/pricing for current rates. |
| Atlassian Guard Standard (formerly Access) Billable User | SSO, SCIM provisioning, API token controls, and authentication policies. Billed per unique managed/external user with access to any supported Atlassian app, counted once regardless of how many products they access. | $3–4/user/month (add-on subscription). Included at no extra charge in Enterprise Cloud plans. |
| Atlassian Guard Premium Billable User | All Guard Standard features plus anomaly detection, SIEM integrations, data classification, and DLP controls. | $8/user/month (add-on subscription). |
- Where to check usage: admin.atlassian.com > [Select Organization] > Apps > User counts > View usage (per product); or admin.atlassian.com/billing > select subscription > Manage > Subscription details > Billed user tab
- How to identify unused seats: Navigate to admin.atlassian.com > Apps > User counts > View usage > Export users. The exported CSV includes each user's last-seen date per product instance. Filter for users with no recent activity and manually revoke access one by one, or automate via the Get user stats API.
- Billing notes: Monthly subscriptions use per-user pricing; users are billed even if they never log in after being invited. Some monthly plans use maximum-quantity billing: the highest user count reached during the billing period is charged, and removing users mid-cycle does not reduce the current month's bill but frees seats for reallocation. Annual subscriptions use fixed user tiers; exceeding the tier is a hard stop requiring a tier upgrade. Enterprise plans are billed at the organization level, not per site. Guard Standard billing counts each unique managed/external user once across all products - a user with Jira + Confluence access is billed as one Guard user, not two. Sites have separate bills; Guard Standard has its own separate bill.
The cost of manual management
Every app in Atlassian's ecosystem shares the same billing trap: users are counted toward billing the moment they are invited, before they accept or log in.
On monthly plans that use maximum-quantity billing, the highest user count reached during the billing period is what gets charged - removing users mid-cycle does not reduce that month's bill.
There is no native CSV import in the Cloud admin UI. Bulk user creation requires entering email addresses manually or scripting against the REST API.
Identifying unused seats means exporting a CSV from admin.atlassian.com > Apps > User counts > View usage, then filtering by last-seen date - a manual step with no automated cleanup built in.
Annual subscriptions use fixed user tiers; exceeding the tier is a hard stop requiring a tier upgrade, not a soft overage. Guard Standard carries its own separate bill from product licenses, adding a second billing line to track.
The decision
Manual administration is viable for small, stable teams where every app's user roster changes infrequently and the org has a single site. The admin console path is straightforward: admin.atlassian.com > Directory > Users > Invite users.
For orgs managing multiple sites, frequent onboarding/offboarding, or needing SSO enforcement, the manual approach breaks down quickly. The lack of bulk import, the billing-on-invite behavior, and the role complexity across centralized vs. original user management experiences all compound at scale.
Teams that have claimed their domain and are already paying for Guard Standard should evaluate SCIM provisioning from their IdP - it removes the manual invite step but introduces its own caveats around license assignment (SCIM groups do not automatically assign product licenses).
Bottom line
Atlassian's admin model is powerful but layered in ways that create real operational cost at scale. The four-role platform hierarchy, split billing between product licenses and Guard Standard, and the billing-on-invite behavior mean that every app access decision carries an immediate financial consequence.
Manual administration works for small, static teams, but the absence of bulk import tooling, the mandatory annual SCIM token rotation, and the dual-role requirement for Site Admins in centralized user management all signal that orgs growing past a handful of users will need to invest in either IdP-driven provisioning or scripted automation to keep access clean and costs predictable.
Automate Atlassian workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
