Understand user provisioning

We support user provisioning using the System for Cross-domain Identity Management (SCIM), and this feature uses the SCIM 2.0 version of the protocol.

User provisioning integrates an external user directory with your Atlassian organization. This integration allows you to automatically update the users and groups in your Atlassian organization when you make updates in your identity provider. For example, with user provisioning, you can create, link, and deactivate managed Atlassian user accounts from your identity provider.

Who can do this?
Role: Organization admin
Plan: Atlassian Guard Standard

Supported identity providers

You can use the identity provider of your choice, but some capabilities are only available with selected identity providers. Learn which identity providers we support

The steps involved to set up user provisioning will differ depending on the identity provider you use. Here are setup instructions for some of the commonly used identity providers:

If you want to use an identity provider that isn’t supported, you can use the user provisioning API to create your own integration that allows you to manage users and groups.

Before you configure user provisioning, you’ll need to add your identity provider to your Atlassian organization. Learn how to add an identity provider

Available attributes for mapping

This is the attribute mapping between an identity provider and your Atlassian organization.

SCIM attribute

AtlassianCloud attribute

nickName

Publicname

The way you map attributes changes depending on your identity provider. Check out the step-by-step instructions for Okta, OneLogin, and Microsoft Azure AD.
Learn how to map attributes

Supported products

Provisioning is available for all Atlassian accounts, which means that you can create, update, and deactivate accounts from your identity provider. Syncing groups is only currently available for Jira product instances, Confluence, Trello and not yet available for Bitbucket.

When a Trello Enterprise is linked to an Atlassian organization, any users who were already provisioned to the organization via SCIM, as well as any users provisioned this way going forward, will have a free Trello account provisioned. The account will be managed by the Trello Enterprise but will not have an Enterprise license unless granted one by an admin.

How user provisioning works

After you connect your identity provider to your organization, your users and groups sync to your organization and sites, making them available for granting product access. This diagram illustrates how users and groups sync once you set up user provisioning.

Diagram of identity provider connecting to your organization - your users and groups sync to your organization and sites

The next few sections break down how the synchronization works:

  • Allowed number of groups and users

  • Users and groups sync from your identity provider to your organization

  • Your organization’s directory syncs to all associated sites

  • Groups get assigned to products

Learn more about user provisioning in this video

Allowed number of groups and users

A large number of groups and users can take a while to sync to an Atlassian organization. These are the limits for how many groups you can sync.

You can only sync up to:

  • 300,000 users per organization

  • 150,000 users per group.

  • 200,000 groups per identity provider directory. To add more groups, contact customer support.

Users and groups sync from your identity provider to your organization

When you set up user provisioning, you create a directory for your users. All users and groups in your identity provider from your verified domain(s) or from outside your verified domain(s) sync to your organization's directory, as shown in the diagram.

You create the groups to provision to your identity provider directory. For some organizations, you continue to see a group we create called All members for directory - <directory_id>, and add all users to.

If you use Google Workspace, you will see a group we created called All users for Google Workspace.

Diagram of identity provider for different groups syncing with your organization

After you connect your identity provider to your Atlassian organization, synced directory groups appear in your Atlassian organization and you're unable to make changes to a user's account from the organization.

If your Atlassian organization already has existing users from a verified domain:

  • And the identity provider has a user with the same email address as a user in your organization, we create a link between both user accounts. You can only make changes to the user's account from your identity provider.

  • And the identity provider doesn't have a user with the same email address as a user in your organization, the user's access remains the same and you can still manage that user from your Atlassian organization.

If your Atlassian organization already has existing users from an unverified domain:

  • And the identity provider has a user with the same email address in your organization, we create a link between both user accounts. You can only make changes to the user’s account from your identity provider.


    You may want to avoid syncing an existing user from an unverified domain. The user may get access to content in your organization or product access, based on how you set up groups to sync from your identity provider.

    We recommend you verify the domain for these users to control access to your organization’s content and access to Atlassian products. How to verify a domain

Syncing more than 500 groups will take a significant amount of time. Be prepared to wait a while for the sync to complete.

Your organization’s directory syncs to all associated sites

Any sites you've added to your organization now have access to your provisioned users and groups, as shown in the diagram. Synced directory groups will appear along the default and native groups in your sites.

Diagram of your organization’s directory syncing to all associated sites

Groups get assigned to products

You can start granting users product access by assigning groups to your site's products.

Diagram of cloud sites getting assigned to Jira Software an to Confluence

When users have product access, Jira and Confluence admins can update product permissions for those users from the Jira and Confluence settings. See Manage global permissions for administering Jira permissions and Manage global permissions in Confluence administration for administering Confluence permissions.

User provisioning features

Once you connect your identity provider to your Atlassian organization, you manage all user attributes and group memberships from your identity provider. If you want to manage users from your Atlassian organization, disable the connection with your identity provider.

Manage group names

  • Rename groups after they've synced to your Atlassian organization. You’ll need to create a new group with the desired name, update its membership, and delete the old group.

Resolve group conflicts

Supported user account operations

When you perform these user management operations from your identity provider, your updates will sync with your Atlassian organization.

We sync user accounts from your identity provider to your Atlassian organization when they have email addresses from your verified domain(s) and from outside your verified domain(s).

Operations

Notes

Create a new user account

A user account gets created when it has an email address from your verified domain(s) or from outside your verified domain(s).

Link an existing user account

If an Atlassian account already exists on the Atlassian platform, we'll automatically link the user in your identity provider to the user in your Atlassian organization.

Update a user's account details

You can update these user attributes from your identity provider:

  • Display name: This is a combination of a user’s first and last name. If you update the display name it also overwrites the attributes for first and last name.

  • Email address

  • Organization

  • Job title

  • Timezone

  • Department

  • Preferred language

When you update an email address from a verified or unverified domain to an unverified domain it:

  • Removes the user from groups provisioned by SCIM

  • May cause the user to lose product access granted in the SCIM group

To make sure users aren’t removed from product access groups, verify a domain in your Atlassian organization first.

About attributes for users outside of your verified domain

Users from outside your verified domain aren't managed accounts. When you update attributes in your identity provider for these users, we won't sync the updates.

Activate a user account

You can activate a user's Atlassian account from your identity provider.

Deactivate a user account

You can deactivate the Atlassian account for users from your verified domain in the identity provider.

When you deactivate users outside your verified domain:

  • User is removed from group provisioned by SCIM

  • User could lose product access granted in the SCIM group

  • User has Atlassian site access

To remove site access after deactivation, you can remove the user from the site.

Delete a user account

We recommend you deactivate a user's account in your identity provider before you delete a user account.

To delete a user's Atlassian account from your verified domain, delete the user from the Atlassian directory in your organization.

Unable to delete user account for users outside your verified domain

When you delete a user from your identity provider, we deactivate the user account. To learn what happens when we deactivate, view the “deactivate a user account” section.

Supported group operations

Use groups to manage admin permissions and product access (new licenses) from your identity provider and these updates will sync with your Atlassian organization.

Any group that is marked as a default group can't be managed via SCIM integration. You can only manage groups synced from your identity provider directory via SCIM.

Operations

Notes

Create a group

The group gets created as a read-only group in the organization's directory. You can only edit groups from your identity provider. Give the new group a name that doesn't already exist your organization.

Delete a group

Delete a group from your identity provider to remove the group from your organization's directory.

Push an existing group

If you try to push a group from your identity provider that has the same name as a group in your organization, you'll get an error.

Update group membership

You can update groups from your identity provider to configure product access, admin privileges, or application-specific settings, such as Confluence space permissions.

Troubleshooting

When troubleshooting issues with syncing users and groups, check the Troubleshooting log on the User provisioning page of your Atlassian organization.

Problem

Workaround / troubleshooting tips

Recorded in log

A group has successfully synced, but the group is empty and doesn't include any synced users.

When pushing a group, make sure that the synchronized group does not have the same name as a default group (e.g. org-admins or site-admins) or a manually created group.

Yes

A group synced successfully, but you don't see it in the site admin area and can't find it on the Product access page.

Make sure you added the site to your organization. To add the site, use the Add a site option from your Atlassian organization.

No

A user seems to be successfully synced, but the user account doesn't appear on the Managed accounts page.

Check that the user's email address is part of your verified domain. 

If the user's account doesn't have an email address with your verified domain, you can navigate to Products > Users page to find the user account.

Yes

(If Okta is your identity provider) Users don't sync to the organization directory when they were already assigned to the Atlassian app before the user provisioning integration is complete.

To sync users correctly, reassign them from the Assignments tab. If a group contains the affected users, you can reassign the group instead.

No

(If Azure is your identity provider) Users don't sync to the organization directory and you're unable to troubleshoot with the error description from the Azure log.

Configure a second Atlassian app within Azure so that you have one for your SAML single sign-on configuration and one for user provisioning.

No

A user's updated email address can't sync because another user (either from the identity provider or not) already has that email address.

You can either:

  • Delete the other user.

  • Change the email address of the other user to a different email address.

Yes

If you have a group name with the same name as an Atlassian built-in group, you won’t be able to sync the group to your organization from your identity provider.

Built-in groups

  1. atlassian-addons

  2. atlassian-addons-admin

  3. site-admins

  4. org-admins

  5. administrators

  6. system-administrators

Go to your identity provider and rename the conflicting group with a name that is different from an Atlassian built-in group name and try syncing again.

 

No

We won’t update the listed user attributes in the Atlassian product for users outside of your domain. You will need to manually update them in the Atlassian product.

Still need help?

The Atlassian Community is here for you.