Understand problems with nested groups

This page outlines the challenges associated with migrating nested groups to Atlassian Cloud and how you can avoid them. In summary, nested groups aren’t supported in Atlassian Cloud, but you can keep the nested structure in your external user directory and use the flattened one in Cloud.

What are nested groups?

Nested groups are subgroups of other groups. They’re typically used for permission inheritance or to recreate the company’s structure in your external user directory.

Here’s an example of a nested structure that you can have in your external user directory:

• Parent group: Atlassian

• Nested groups: Design, Engineering, Grads

The main benefit of a nested structure is the permission inheritance. The members of nested groups will not only receive permissions from their direct groups, but also from the parent group. This is commonly used to easily grant or revoke permissions. In such a structure, you can just add a user to a single nested group (and have them inherit memberships and permissions from all parent groups) instead of adding them to each group individually.

How are nested groups synced to Cloud?

Atlassian Cloud doesn’t support nested groups and most Cloud identity providers don’t allow syncing a nested structure into any SaaS application.

When you sync your users to Atlassian Cloud over SCIM without flattening, the following happens.

• Groups: All groups are synced, but the nested structure isn’t preserved. The groups live on the same level.

• Group memberships: Users lose memberships in the parent groups. The permission inheritance isn’t respected.

This problem mostly applies to syncing from Microsoft Azure AD using SCIM, which doesn’t support flattening. You can solve it by using our custom integration: Azure AD for nested groups.

Flattening nested groups

To solve this problem, nested groups can be converted into a flat structure while keeping all effective group memberships.

When you flatten nested groups, the following happens:

• Groups: All groups become separate groups, and live on the same level.

• Group memberships: Users are added to each group individually, without relying on permission inheritance. For example, if they were a direct member of a nested group and inherited membership in the parent group, after flattening they will be a direct member of both these groups. This is an ongoing process that’s also applied to any new users and groups.

How are nested groups migrated?

When you migrate with one of the assistants, we’ll flatten your nested groups. This is similar to syncing from an identity provider that supports flattening – users that were previously indirect members of the parent groups will become their direct members after the migration.

Choose an identity provider that supports flattening

Many identity providers support flattening by default. We’ve also built our custom integrations, such as Google Workspace or Azure AD for nested groups, which can flatten your groups while syncing them to cloud. Open the page below to view the list of identity providers that are best suited for migrations.

Learn how to choose the right identity provider for the migration

Related pages

Get started with migrating users to Atlassian Cloud