Problem Statement:

As an Administrator, I am unable to preserve group memberships when performing a full production-to-sandbox copy ("Copy all spaces or projects"). As a result, my users lose access to boards and projects in the sandbox immediately after a sync, requiring tedious manual intervention to restore permissions for hundreds of users.

Issue Summary:

Currently, the "Preserve group memberships" toggle is only available when performing a selective copy ("Copy specific spaces or projects"). When an administrator chooses to "Copy all spaces or projects," the system merges users and groups but does not provide a way to explicitly preserve memberships. This often results in groups being created in the sandbox with 0 members, causing immediate permission blocks (e.g., "Browse Projects" errors) for users who should have inherited access. This behavior is inconsistent across the sandbox copy tools and creates significant overhead for large organizations.

Replication steps:

• Navigate to admin.atlassian.com > Sandbox.
• Select Copy data > Jira.
• Choose Copy all spaces or projects.
• Observe that the "Preserve group memberships" checkbox is missing from the configuration screen.
• Complete the copy and observe that groups (e.g., jira-users) exist in the sandbox but have 0 members, despite having hundreds of members in production.

Idea:

The "Preserve group memberships" toggle should be added to the "Copy all spaces or projects" flow to ensure parity with the selective copy tool. This would allow administrators to maintain access settings and user-to-group mappings during a full site refresh without needing to run multiple manual syncs or scripts.

Work Around (optional):

1. Perform a selective copy ("Copy specific spaces or projects") for the critical projects and select the "Preserve group memberships" toggle.

1. Manually add users to the required groups in the sandbox via admin.atlassian.com after the copy completes.