For AI agents: a documentation index is available at /llms.txt. A markdown version of this page is available at /guide/cloud/admin/teams-and-business-units.md.
Teams and business units
Group people so access, reporting and planning follow your organisation instead of fighting it.
Teams on Pro, business units on Premium
Team management requires Pro Unlimited. Business units and organisational structuring are Premium.
#Teams
A team is a named group of people. Its value is that membership becomes a property of the team, not of every project individually.
A new joiner is added to eleven projects by hand. Someone forgets one, and they cannot see the work for a week.
Add them to the team. Project access follows.
#Designing teams
Mirror how people actually work
Teams that reflect real working groups stay accurate. Teams that mirror the org chart go stale within a reorg.
Keep them stable
A team reshuffled monthly provides no benefit over individual assignment.
Give each an owner
Someone responsible for membership.
Don't over-split
Six people in three teams of two is overhead with no payoff.
#What teams give you
| Use | Effect |
|---|---|
| Project access | Add the team, not eleven people |
| Assignment | Assign to a team, let them pick up |
| Reporting | Velocity and workload per team |
| Resourcing | Capacity at team level |
| Notifications | Notify a group |
#Business units Premium
A level above teams: divisions, departments, regions, or legal entities.
Use them when you need to report and budget at a level above the team — "how is the EMEA division tracking against budget?" — not merely to draw an org chart.
Separate P&Ls, distinct budgets, or reporting lines that must not see each other's detail.
One company, one budget, forty people. Teams are enough.
#What they give you
- Budget and cost reporting rolled up by unit
- Resource capacity and utilisation at unit level
- Access boundaries between parts of the organisation
- Portfolio views scoped to a division
#Structure that survives
Don't rebuild your org chart
Org charts change constantly. Model how work is actually grouped, which changes far less, and you will not be rebuilding this every reorg.
Two levels is usually enough
Business unit → team → people. Deeper hierarchies produce reports nobody reads and access rules nobody understands.
People work across boundaries
Someone can be in more than one team. Structure should not force you to pretend otherwise.
Review after every reorg
Stale structure quietly grants access that should have been removed.
#How this interacts with projects and programs
| Concept | Groups |
|---|---|
| Team | People |
| Business unit | Teams |
| Project | Work |
| Program | Projects |
Teams and business units organise who; projects and programs organise what. They are independent — a program can draw on several teams, and a team can work across several programs.