Structure your organization using units
This feature is currently in beta and is gradually rolling out. It may not be available to all organizations at this time.
Unit allows you to set your organizational footprint and helps you create a collaboration boundary for users, groups, apps, and data, allowing you to separate specific work while maintaining shared organization-level security configuration.
When to create a unit
Since units create a collaboration boundary, use them only when users and their work need a separate collaboration boundary.
Before you set up units, carefully plan your organizational footprint to avoid creating unintentional data silos.
Taking the time to plan before you enable units helps you:
Optimize collaboration: Ensure the right teams can find each other and share knowledge easily.
Set data boundaries: Keep sensitive projects or regional data separate where required.
For example, a global consulting firm might use units to manage projects for competing clients. By placing each client's work, apps, and consultants into separate units, the firm establishes clear collaboration boundaries; the team working for Client A won't see new activity or content from Client B's unit, even though both teams belong to the same parent organization.
Similarly, units are ideal for managing subsidiaries, regional standalone operations, or highly sensitive internal projects that require strict isolation.
Refer to this table to understand when you should create organizations, units, sites, apps, or spaces.
Create a new | When you |
|---|---|
Organization | Need a separate instance of Atlassian Cloud with its own administration interface, subscriptions, billing management, and security policies. |
Unit | Need another user directory and collaboration boundary in your existing organization. Existing organization-level security policies still apply across units. |
Site | Need another site for your apps within the same collaboration boundary. Access to its content is still controlled by app permissions. A seperate site helps manage admin delegation so that different admins can manage different sites within the same unit boundary. |
App | Want a separate app instance with a different URL to invite a subset of users and groups from your directory; an app admin will need to manage the settings and permissions for this app separately. |
Space | Want to organize work in an existing app, but only give certain people invited to the app permission to view and edit the content in that space. |
Ideal use cases
Scenarios | How units support this |
|---|---|
Consulting firms and managed service providers You manage client engagements where user visibility, search results, and project data must be strictly isolated between client accounts. | Create dedicated units per client engagement. Each unit maintains an independent user directory and Teamwork Graph, ensuring search, Rovo, and cross-app experiences only surface data within that specific client boundary. |
Large enterprises with regional divisions You operate across global regions and need to meet regional compliance, data residency, or localized administration requirements. | Establish regional units to keep data and team collaboration scoped locally, while retaining centralized organization governance and unified Enterprise billing. |
Organizations with multiple subsidiaries or brands You oversee distinct operating entities or brands that require separate workspaces and local management under a single organization. | Provision each subsidiary in its own unit and assign a unit admin to manage local users, groups, and apps without granting organization-wide administrative permissions. |
M&A, legal, and confidential initiatives You handle sensitive work, such as mergers, acquisitions, legal, or restricted R&D, where data must remain strictly isolated from the broader company. | Place confidential projects in a dedicated unit with restricted membership. Rovo, AI recommendations, and search are restricted to the unit, preventing sensitive content from appearing to users outside the boundary. |
Cloud migration or org consolidation You are migrating multiple Data Center instances or consolidating disparate cloud sites into a single Atlassian organization. | Consolidate onto a single Cloud Enterprise organization while using units to preserve structural separations between business units, teams, or regions. |
When to use multiple sites instead of units
If you mainly want to give a team its own space to work, its own admins, or its own app configuration, you probably don't need a new unit. Instead, add another site to the same unit. Every site in a unit shares one user directory and one Teamwork Graph, so people can still collaborate across sites. Each site can still have its own admins, settings, and permissions.
You don’t need to use units when every user, agent, and app needs to share a single organization boundary.
Example organization with a single boundary
Example organization with multiple sites in the same unit
What changes with units
Units change how you manage your organization and how users interact across boundaries. How units impact organization administration and end user experiences
What stays the same with units
While units introduce new boundaries, many core elements of your Atlassian organization remain unchanged:
Existing users: Your current users remain in the organization and remain members of their existing user directories
Permissions: App-level, space-level, and project-level permissions continue to function as configured.
Data: Your existing pages, work items, and files remain intact.
Integrations: Most existing integrations continue to work, though you should review those that require cross-boundary access.
Security: Units inherit all organization-level security and access policies. How units impact organization administration
If you are in the original user management experience, each site and its user directory gets its own unit. They only share a boundary when you merge units.
Was this helpful?