How units impact organization administration
This feature is currently in beta and is gradually rolling out. It may not be available to all organizations at this time.
Who can do this? Role: Organization admin Atlassian Cloud: Enterprise plan Atlassian Government Cloud: Not available |
|---|
Setting up units introduces a new layer of administration that changes how certain organization-wide configuration are applied. While many security and billing settings remain centralized, configurations like user provisioning and sandboxes become unit scoped.
What remains organization-scoped
These configurations don’t change with units and continue to be managed at the organization level by organization admins.
Billing and subscriptions: All units and sites remain under a billing account.
Identity and security: SSO, MFA, and global security policies (like password requirements) apply to all users in the organization regardless of their unit.
Organization-wide audit logs: A master log of all activity across all units remains available to organization admins
What changes with units
When you enable units, some changes happen automatically, while others require manual configuration.
Automatic changes include:
Existing sites and users are automatically grouped into a unit.
The administration interface updates to include unit-scoped management views.
If you are in the original user management experience,
Existing sites and users are mapped to individual units.
Site admins become unit admins for their respective units.
See Structure organization with units
Feature | Before units | After units |
|---|---|---|
User provisioning | Users were provisioned to the organization and gained access to sites based on global rules. | Allocation policies determine which unit a user or group is synced to. How to build an allocation policy |
Sandboxes | Sandboxes were linked directly to a production site. | New sandboxes are connected to a sandbox unit, which links to a production unit. Unit admins can create and manage sandbox apps and units connected to the production units they administer. |
Data residency | Managed at the site or app level across the organization. | Managed at the unit level for supported apps, allowing regional grouping of data. More about data residency configuration |
App links | Links between apps (such as Jira to Confluence) worked across the whole organization. | New links are primarily unit-scoped. Cross-unit links may require specific exceptions or collaboration tools. More about app links |
Service accounts | Service account list was org scoped | Service accounts are not bound to a specific unit and directory within an org |
Audit logs | Only org admins could view audit logs | Unit admins can view audit logs for the units they administer |
Guard / Guard Premium | Guard/Guard Premium configuration setup at the org level by org admins | No change |
After enabling units, use this checklist to ensure your configuration is correct:
SCIM routing: Confirm new users are appearing in the correct unit directory.
App access: Verify that global apps are enabled and functional within each unit.
Admin scoping: Ensure unit admins can access only the units they are assigned to.
Search and Rovo: Test that Search and Rovo results are correctly scoped to the unit boundary.
Sandbox connectivity: Confirm whether existing sandbox sites and apps should remain in a production unit, or be re-created as part of a sandbox unit
Was this helpful?