Managing user access and permissions is a critical responsibility in any Atlassian Cloud environment. As organizations scale their use of Jira and Confluence, controlling who can access what, and at what level, becomes essential for security, compliance, and day‑to‑day operations.

In Atlassian Cloud, user access is managed centrally through the admin.atlassian.com portal. This centralized approach allows administrators to control access across Jira, Confluence, and other Atlassian products from a single location, rather than managing permissions separately in each tool.

From the admin portal, administrators can invite users, assign product access, and define roles such as product users, product admins, and organization admins. Access is typically granted through groups, which makes it easier to scale permissions as teams grow or change. Instead of managing individual users, admins can add or remove users from groups and let permissions update automatically across spaces.

At the product level, Jira and Confluence provide granular permission models. In Jira, administrators control access through space permissions, issue security schemes, and roles. In Confluence, access is managed through space permissions and page‑level restrictions. This allows organizations to balance openness with control, ensuring users have the access they need, no more and no less.

Atlassian Cloud also supports enterprise‑grade security controls. Administrators can configure SAML single sign‑on (SSO), enforce authentication policies, and manage user lifecycle events centrally. These controls help reduce risk, support compliance requirements, and simplify onboarding and offboarding across global teams.

When set up correctly, centralized access and permission management in Atlassian Cloud reduces administrative overhead, improves security, and creates a consistent experience for users across Jira and Confluence.

Illustration of people using a key to unlock a secure system, representing controlled user access and permissions.

Key Aspects of User Management in Atlassian Cloud

1. Access Control and User Lifecycle Management

Access control in Atlassian Cloud is managed centrally through admin.atlassian.com, allowing organization administrators to control user access across Jira, Confluence, and other Atlassian products from one place.

All users are managed in the Directory, which serves as the authoritative source for user accounts, especially for managed accounts, where the organization has verified and claimed the user’s email domain.

Where to Manage Users

To manage users:

Go to admin.atlassian.com and select your organization.
From the sidebar, select Directory, then Users.
Search or browse to find the user you want to manage.

From this screen, administrators can review access, manage roles, and take action on user accounts.

Deactivating User Accounts

Deactivation is the recommended approach when a user leaves the organization or no longer needs access. Deactivated users lose access to all Atlassian products, but historical data such as Jira work items and Confluence pages is preserved. The user can also be reactivated later if needed.

To deactivate a user:

Open the user’s profile from the Users list.
Select the More actions (•••) menu.
Choose Deactivate account.

Important considerations:

Only managed accounts can be deactivated directly in Atlassian Cloud.
If you use SCIM provisioning with an identity provider (such as Okta or Azure AD), users must be deactivated in the IdP. Atlassian will sync the change automatically.
For unmanaged accounts, admins can suspend access rather than deactivate.

Deleting User Accounts

Deleting a user is a permanent action and should be used with caution. The user is removed from all Atlassian services, including Marketplace and Community. Deleted accounts cannot be restored after 14 days. Also, historical content remains, but the user identity is removed.

To delete a managed account:

Open the user’s profile from the Users list.
Select the More actions (•••) menu.
Choose Delete account.

Deletion is typically reserved for compliance or data‑cleanup scenarios.

Managing users in Atlassian Cloud

2. Assigning Roles and Administrative Permissions

Atlassian Cloud uses a role‑based model to separate responsibilities and reduce risk. Roles determine what a user can manage, not just what they can see. All role assignments are managed from the User Directory in admin.atlassian.com.

App Admin

An app admin manages configuration for a specific product, such as Jira or Confluence. App admins cannot access organization‑level settings.

Common responsibilities include:

Managing space settings
Configuring workflows, schemes, or templates
Administering product‑specific features

To assign an app admin role:

Go to Directory → Users.
Select a user.
Choose Grant access.
In the Roles column, select App admin for the relevant app.
Select Grant access.

For Jira, this role is assigned under Jira Administration, as Jira apps share the same admin console.

User Access Admin

A user access admin manages who can access a specific app.

Typical responsibilities include:

Granting or revoking product access
Assigning users to groups
Ensuring users have appropriate licenses

To assign the user access admin role:

Go to Directory → Users.
Select a user.
Choose Grant access.
Select User access admin in the Roles column.
Select Grant access.

This role is useful for delegating access management without granting full admin privileges.

Site Admin

A site admin manages apps and settings for a specific Atlassian site.

Responsibilities include:

Installing and managing apps
Managing site‑level settings
Supporting day‑to‑day administration

To assign a site admin role:

Go to Directory → Users.
Open the user’s profile.
Select the More actions (•••) menu.
Choose Assign site admin role.
Select Site admin for the relevant site and grant access.

Note: Site admins may still require an app license to perform certain actions, especially in Jira.

Organization Admin

The organization admin role has the highest level of access.

Organization admins can:

Manage users and domains
Configure security policies (SSO, authentication, SCIM)
Assign admin roles
Access organization‑wide analytics and settings

Best practices:

Always have more than one organization admin.
Limit this role to a small, trusted group.
If an organization admin becomes unavailable, Atlassian Support can assist with a role transfer after verification.

Assigning a site admin in Atlassian Cloud

3. Groups and Permission Scaling in Atlassian Cloud

Groups are the foundation of scalable user and permission management in Atlassian Cloud. Instead of assigning access and permissions to individual users, administrators use groups to manage access in bulk across Jira, Confluence, and other Atlassian products.

All group management happens centrally through admin.atlassian.com, making it possible to control product access, site‑level permissions, and space roles from a single place. This approach is essential for organizations with growing or global teams.

Groups allow administrators to:

Grant or remove product access for many users at once
Assign Jira space roles and Confluence space permissions consistently
Reduce manual effort and the risk of misconfigured access
Support onboarding and offboarding at scale

When groups are designed well, access changes become predictable and easy to manage.

Creating and Managing Groups

Organization admins manage groups from the Directory in Atlassian Administration.

To create a new group:

Go to admin.atlassian.com and select your organization.
Navigate to Directory → Groups.
Select Create group and follow the prompts.

After creating a group, you are taken to the group profile. From there, you can select Grant access to give the group access to Jira, Confluence, or other apps. When access is granted, users in the group are automatically invited to the app if they do not already have access.

To edit a group:

Go to Directory → Groups.
Open the group you want to modify.
Use the More actions (•••) menu to rename the group or update its description.

Clear group names and descriptions are important. They help administrators understand what access the group provides and reduce confusion over time.

Deleting Groups Safely

Groups should be deleted only when they are no longer needed.

Before deleting a group:

Check whether the group is used in Jira permission schemes or Confluence space permissions.
Remove or replace those permissions if users still need access.
Be aware that deleting a group does not remove users from the organization.

To delete a group:

Go to Directory → Groups.
Open the group profile.
Select the More actions (•••) menu.
Choose Delete group.

Default groups for app roles cannot be deleted. Group deletion can also be automated using the Atlassian Delete Group API for larger environments.

Understanding Default Groups

Default groups play a critical role in how users gain access to Atlassian apps. When you add an app to your organization, Atlassian automatically creates default groups for each app role. When a user is granted access to an app or assigned a role, they are automatically added to the relevant default group.

This behavior is convenient, but it can also cause problems if not managed carefully.

Common risks include:

Unintended license consumption
Users gaining access earlier than expected
Confusion when default and custom groups overlap

Users can be added to default groups in several ways:

Directly through Atlassian Administration
Indirectly through custom groups that grant app access
Automatically through synced groups from an external identity provider

To avoid issues, administrators should:

Review and limit which groups are set as default
Use custom groups for most access control
Ensure identity provider group mappings are intentional and documented

4. Product‑Specific Permissions in Jira and Confluence

While user access and groups are managed centrally in Atlassian Cloud, permissions are enforced at the product level. Jira and Confluence each apply permissions differently because they support different types of work.

Permissions in both tools follow a layered approach. A user must first have application access through group membership. Only after that do space‑level permissions apply. Once access is granted, Jira and Confluence use distinct permission models to control what users can see and do.

Jira Permission Model

Jira permissions are built around work tracking, workflows, and roles within spaces. They control how users interact with work items, from viewing and creating them, to managing workflows and administration.

Jira uses a structured model made up of several core components:

Permission schemes, which define what actions are allowed within a space, such as browsing spaces, creating or editing work items, assigning work, and transitioning workflow statuses. These schemes are created once and reused across spaces to maintain consistency.
Space roles, which act as placeholders within permission schemes. Instead of assigning permissions directly to users or groups, roles such as Developers, Product Owners, or Viewers are used. Users and groups are then mapped to these roles at the space level, making changes easier when teams shift.
Work item security schemes, which restrict visibility of individual work items inside a space. These are used when certain work items contain sensitive information and should not be visible to all space members. Security levels are defined using users, groups, or roles and override standard space visibility.
Global permissions, which control system‑wide capabilities such as logging in, creating shared objects, or administering Jira. These permissions should be tightly limited to trusted administrators.

Together, these elements allow Jira to support complex, role‑based workflows while maintaining control over sensitive work.

Confluence Permission Model

Confluence permissions are designed around content creation, collaboration, and information sharing. Access is primarily controlled at the space and page level, rather than through workflow roles.

Confluence permissions are managed through three main layers:

Global permissions, which determine who can access Confluence at all and who can perform administrative actions like creating spaces or managing users. Without global access, users cannot interact with Confluence content.
Space permissions, which control what users can do within a specific space. Managed from Space settings → Permissions, these permissions define who can view content, create or edit pages, comment, attach files, or manage the space itself. Space permissions are typically assigned to groups to support scale.
Content (page‑level) restrictions, which allow space admins or page creators to limit who can view or edit individual pages. These restrictions override space‑level permissions and are useful for protecting sensitive or draft content within an otherwise open space.

This model supports open collaboration while still allowing precise control where needed.

Key Differences Between Jira and Confluence Permissions

Although both products rely on group‑based access, their permission models reflect different goals. Jira permissions focus on structured processes, workflows, and work ownership. Confluence permissions focus on content visibility, collaboration, and knowledge sharing.

Recognizing this difference is essential when designing a consistent and secure access model across Atlassian Cloud.

5. User Invitations and Security Controls

User invitations play a central role in access management within Atlassian Cloud. Decisions about who can invite users and how those invitations are handled directly affect security, licensing costs, and governance, especially in large or distributed organizations.

All invitation and access controls are managed through admin.atlassian.com, which allows administrators to standardize onboarding and reduce the risk of unauthorized access.

Controlling Who Can Invite Users

Invitation behavior is configured through App access settings in Atlassian Administration. These settings determine which users are allowed to send invitations, whether invitations require approval, and what level of product access is granted by default.

Limiting invitation rights to a small set of administrators helps prevent unplanned license usage and ensures new users are onboarded with the correct access from the start. In mature environments, this control is critical to maintaining predictable growth and cost management.

Inviting Users to Atlassian Cloud

Inviting users is handled from the User Directory in Atlassian Administration. Administrators select their organization, navigate to Directory → Users, and choose Invite users. Email addresses are entered, product access is assigned for Jira, Confluence, or other apps, and users are added to the appropriate groups to apply permissions.

Invitation messages can be customized, or administrators can create accounts without sending an immediate email. This option is useful when onboarding needs to be coordinated with internal processes or identity systems. Until the invitation is accepted, users appear with an Invited status.

Security and Governance Considerations

Domain verification is a key security control in Atlassian Cloud. When an organization verifies and claims its email domain, invited users become managed accounts. This allows administrators to enforce authentication policies, manage the full account lifecycle, and apply security and compliance settings consistently.

Atlassian Cloud also supports guest access, primarily in Confluence. Guests have limited access to specific spaces and do not consume full licenses, making them suitable for controlled collaboration with external users.

For larger onboarding needs, the admin interface alone may not be sufficient. In these cases, organizations typically rely on SCIM provisioning from an identity provider or Atlassian APIs to automate user creation and deactivation. Some environments also require administrative approval before invitations are finalized, adding another layer of governance.

Secure, Scalable Access Management in Atlassian Cloud

Managing user access and permissions in Atlassian Cloud is not a one‑time setup. It is an ongoing practice that directly affects security, compliance, cost control, and how effectively teams can work.

By using centralized administration in admin.atlassian.com, organizations can control the full user lifecycle, from invitations and role assignments to groups, product access, and detailed permissions in Jira and Confluence. Groups provide the foundation for scale. Product‑specific permission models allow for precision. Invitation and security controls help prevent unintended access and license sprawl.

When these elements are designed together, Atlassian Cloud becomes easier to govern and safer to operate, even as teams grow, change, and work across regions. The result is an environment where users have the access they need, administrators retain control, and leaders gain confidence that the platform is secure and well managed.

The Role of Atlas Bench

As an Atlassian Platinum Solution Partner with deep Cloud specialization, Atlas Bench helps organizations move beyond migration and fully transform how they work on Atlassian Cloud.

We support large teams by:

Assessing security, compliance, and risk across existing Atlassian environments
Mapping regulatory requirements to Atlassian Cloud capabilities
Designing Cloud configurations that align with security and audit expectations
Supporting Cloud migrations with governance and controls built in
Optimizing identity, access, and data management post‑migration
Providing ongoing guidance as Atlassian Cloud capabilities evolve

Our focus is practical outcomes. We help teams adopt Atlassian Cloud in a way that is secure, compliant, and ready to scale.

Interested in learning more? Connect with Atlas Bench to book a complimentary consultation with our Certified Atlassian Experts.

Start transforming collaboration today with Atlassian Cloud. Sign up now to help your team work better together.

Atlas Bench is an Atlassian Platinum Solution Partner with deep Cloud Specialization, helping Data Center customers move beyond migration and fully transform on the Atlassian Cloud Platform. We deliver Atlassian’s System of Work end to end through four collections: Strategy, Teamwork, Service, and Software, connecting planning to execution, aligning teams around outcomes, modernizing service delivery, and accelerating software development.

We are also recognized as an Atlassian World Class Software Development Partner of the Year (Americas), and we bring AI leadership to every engagement. By leveraging Rovo for automation and purpose built agents, we reduce manual work, unlock knowledge across tools, and speed up decision making so organizations realize measurable value faster in cloud.

BLOG

Check our last post

Getting Full Visibility Into Cross-Team Work With Atlassian

Recent Posts