Recommendations for SCIM provisioning with Atlassian Guard

With an Atlassian Guard Standard (formerly known as Atlassian Access) subscription, you can use SCIM to provision user accounts and sync group memberships from your identity provider. The process to set up SCIM user provisioning, and when this should happen, will depend on the products you’re migrating and the data migration method you plan to use.

Before you begin:

• Learn more about user provisioning

• Learn how to determine your user migration strategy

• Prepare for and set up Atlassian Guard

Set up SCIM user provisioning

The process will depend on the products you’re migrating and the data migration method you’re using.

When using the Migration Assistants

You can configure SCIM user provisioning and sync users from your identity provider before or after starting the migration. The Jira Cloud Migration Assistant and the Confluence Cloud Migration Assistant will associate the data using email addresses. It won’t break the user and content association during the data sync and so you can keep SCIM enabled during the migration. The Migration Assistants will also migrate people from both internal and external server directories.

However, when deciding on your strategy, you will want to reduce the risk of creating duplicate Atlassian Accounts. We recommend you start by verifying your domains and claiming accounts so that you identify any issues early. If there is a chance that your users' Atlassian Account email addresses won’t match the primary email addresses in your identity provider, you may want to enable SCIM user provisioning last, after you’ve completed the migration, checked that your users data is mapped correctly, and performed any required changes to Atlassian account email addresses.

Disable SCIM

There are two ways you can disable SCIM:

• Delete provisioning directory on Atlassian. This disconnects Atlassian organization from identity provider (IdP) provisioning, and all Atlassian accounts remain in the same state they were during provisioning. All previously synced groups become local and retain all membership and product associations. After migration, you should reconfigure your identity provider and directory from scratch. We recommend this method.

• Stop or disable provisioning on the IdP. This sends a signal to Atlassian that previously provisioned users are no longer actively maintained from the IdP. Refer to your IdP documentation to know how to temporarily stop or disable provisioning. There is a higher chance of problems occurring when the sync is in a ‘paused’ state, so in most cases we recommend you stop the sync from the identity provider and delete the existing provisioning directory from your Atlassian organization.

Frequently asked questions

How does SCIM work for existing cloud users and groups?

1. If a user was migrated with the Jira or Confluence Cloud Migration Assistant or the user exists on the cloud site with the same email address, the user’s SCIM record will be linked to the existing Atlassian account.

2. If a user was not migrated with the Jira or Confluence Cloud Migration Assistant or the user doesn’t exist on the cloud with the same email address, SCIM sync will create an Atlassian account for the user, or link the SCIM record to an existing Atlassian account.

3. If a managed user is deleted in the identity provider, SCIM will deactivate the user’s Atlassian account. This means they won’t be able to access any cloud products.

4. If a group is deleted in the identity provider the group is then deleted from the cloud site and directory. If the group was used to provide product access or permissions, the group members will lose access. Re-syncing the group, or creating a new group with the same name won’t restore access.

What to do when you run into group conflicts

Group conflict happens when you migrate a group using the Migration Assistants and then you enable the SCIM. SCIM syncs the same group via your identity provider (IdP) that might have a different set of users.

You may run into group conflicts when migrating or after migration. When the sync happens, we’ll warn you about duplicate group names between your IdP and your Atlassian organization. You’ll be able to accept or reject changes to group members before you sync those groups. Learn more about resolving group conflicts before syncing  

How to unlock reporting lines and filters in Atlas

When you’d like show who users report to in Atlas, you can add the manager attribute to your Microsoft Azure AD settings. When you sync users from Microsoft Azure AD, the reporting lines for the user appear in the user profile.
How to sync the manager attribute into Atlas with Azure AD