How user management works in Atlassian Cloud
User management in Atlassian Cloud is different from what you know from Server or Data Center. The main difference is that it’s separated from cloud apps, like Jira or Confluence. If you used Crowd, it would be the closest comparison. This page explains the main concepts of how you’ll manage users in cloud.
Centralized user management
In cloud, users are managed from a central location called admin.atlassian.com, available under the same URL. This is a platform shared by Atlassian cloud apps where you manage, for example:
Users and groups
Access to apps
User provisioning and single sign-on
Apps, subscriptions, billing
When you deploy a cloud app, you always get access to your own admin.atlassian.com. It can only be accessed by organization admins who are a rank higher than Jira or Confluence admins, though they’re really just a different type. Think system admins, though we don’t have system admins in cloud.
Organizations
The admin.atlassian.com platform is divided into organizations – you can have one or more if you prefer to keep things more separated. Every organization has a separate user base, including individual app access, user provisioning configuration, and so on. When accessing the platform, you always choose which org you want to view.
Organizations are further divided into sites that hold app, like Jira and Confluence. All sites (and app) within one organization share the same user base and configuration. You can have many sites, and many apps, within one org.
Learn more about organizations
User management area from Server or Data Center
The user management area that you know from Server or Data Center doesn’t exist in cloud. In server, it’s based on Embedded Crowd – a set of libraries that we’ve embedded in Jira and Confluence for user management. They’re not available in cloud, and you won’t be able to access this area. We’ve moved everything to admin.atlassian.com. On the bright side, it does look a little better.
App access
App access is the first layer of access that controls whether users can even open a specific app. You grant it from admin.atlassian.com together with an additional role (Admin, User, Customer) to groups or individual users. Once it’s granted, all users with app access start counting towards your cloud subscription. This works in the same way as application access in server.
We migrate your app access from server, but we won’t apply it to groups until you confirm it after the migration, because it affects billing.
Learn more about app access in cloud
No app access
Users without any app access still exist and can log in to Atlassian Cloud. But, they won’t be able to do much apart from changing their preferences or uploading an avatar. They won’t count towards your cloud subscription.
Permissions
Permissions are the second layer of access, and allow you to give your users more granular permissions than just access to app – for example, permission to view secret projects or spaces. They work in the same was as in server – they’re managed on the app level, and not from admin.atlassian.com. That’s because they’re really more on the data protection side rather than user management.
Permissions depend on your app, like in server. In Jira, you’d have project roles, permission schemes, and more granular permissions. In Confluence, that’s space permissions, with additional restrictions on pages. We’ll migrate your roles, schemes, permissions, or restrictions when you migrate projects or spaces (with the exception of most global permissions).
Learn more about roles and permissions
Atlassian Guard Standard subscription
Atlassian Guard Standard, although seen as a separate app, is really an expansion for admin.atlassian.com. It’s an additional subscription that enables such features as:
SCIM user provisioning
SAML single sign-on
Data security policies
Organization audit log
When you subscribe to Atlassian Guard Standard, you’ll still manage users from admin.atlassian.com, but you’ll see more tabs, options, and features. If you sync users from external directories (other than Google Workspace), you’ll most likely need Atlassian Guard Standard.
Here’s an example page in admin.atlassian.com that’s available only with an Atlassian Guard Standard subscription – it’s still the same Atlassian Admin area:
Atlassian Cloud accounts
In Atlassian Cloud, users are identified by their email address – every email must be valid and unique. In server, it was the username, that’s why many people have problems with migrating users because of missing or invalid emails. Every user that you create, invite, provision, or migrate will get an Atlassian Cloud account based on their email address.
Access to multiple apps
When users are granted access to multiple apps, they’ll access them through their single Atlassian Cloud account. In server, they would have separate users in each instance.
When you migrate users from multiple Data Center instances (Jira, Confluence), we’ll match them by their email address and link all of their references (mentions, comments, and so on) to their single Atlassian Cloud account.
Accounts vs. managed accounts
Individual users own their accounts by default. You still control app access, but you can’t modify the account itself. If you want more control, you can verify that you own the domain (@atlassian.com) and claim all accounts from this domain. This transfers ownership of the account to the organization that verified the domain, and the accounts become managed accounts. They’re the same accounts, you just have more control. Atlassian Guard Standard specific features can be used only for managed accounts.
Logging in with emails
A key difference for users when they log in is that they’ll use their email address instead of logging in with their username as they previously did in server.
If you’re using single sign-on in cloud, users will log in through single sign-on and have the same password.
If you don’t use single sign-on, users need to select “Forgot password” and enter a new password. Passwords aren’t migrated.
Users will need to upload new avatars, as they aren’t migrated.
User provisioning and authentication
You can manage and sync users from external directories to cloud, but there are additional requirements:
Cloud identity providers
You can’t connect an external directory directly to admin.atlassian.com. You’ll need a cloud identity provider in-between. If you don’t have one, in this guide you’ll find a list of IdPs that are best suited for migrations. We also have a partnership with Okta that lets you set up a free account.
Subscription for Atlassian Guard Standard
You’ll need a subscription for Atlassian Guard Standard to enable SCIM user provisioning and SAML single sign-on. If you use Google Workspace, you can use our integration for user provisioning that doesn’t require Atlassian Guard Standard, but has limited functionality without this subscription.
Here’s how it all connects:
No user provisioning or authentication
If you don’t configure user provisioning, you can create and update users in admin.atlassian.com, just like in the Jira or Confluence internal directories. If you don’t configure single sign-on, users will log in with their emails and passwords. Passwords must be reset after migration, as they’re not migrated.
Other differences related to user management
Here are some other differences or information you should know about.
Nested groups
Atlassian Cloud doesn’t support nested groups. You can still have nested groups in your external directory, but you’ll need to flatten them when syncing to cloud. In admin.atlassian.com, they’ll always appear on the same level. Most cloud identity providers support flattening, we’ve also built custom integrations that flatten groups when syncing from Google Workspace or Microsoft Azure AD.
Duplicate group names
All groups are managed from a single location, so you can’t have multiple groups with the same name. When you try to migrate a group whose copy already exists, we’ll migrate its users, but not the group itself. This is important if you’re migrating from both Jira and Confluence. If each of these Data Center instances had a group admins with a different set of users, after migration all of these users would belong to a single admins group, with access coming from the group that was migrated first. Permission escalation at its finest. This guide will tell you more about that.
Crowd Server or Data Center
Crowd doesn’t have an equivalent cloud app, although admin.atlassian.com works in a similar way. If you’d like to continue managing users in Crowd, you can connect it to a cloud identity provider, and then connect the provider to admin.atlassian.com.
Related pages
Was this helpful?