Skip to main content

Teams and sub-teams

Create teams under your organization, sub-teams under a team, and understand when to nest.

A Team is a child of the Organization. A Sub-team is a child of a Team. The two together cover the structural side of access control — who reports into what, and which roles apply at which scope.

When to add a Team

Add a Team for any meaningful organisational grouping that should have its own roles. Common patterns:

  • Functional teams: Performance Marketing, Creative, Strategy, Analytics.
  • Geographic teams: EMEA, AMER, APAC — when each region has its own staff and clients.
  • Brand / business units: Acme Brand, Acme Lifestyle — when an in-house marketing team manages multiple brands as separate workspaces inside the same Level org.

Don't create a Team for every small grouping. Granular access is what Sub-teams and roles are for.

When to add a Sub-team

Sub-teams are children of a Team and the deepest level the hierarchy supports. Add one when:

  • A subset of a team needs its own role that shouldn't apply to the whole team. Performance team has a role Reporting Lead that only the Google Ads sub-team should hold? Define it on the sub-team.
  • Membership is meaningfully smaller. Performance team has 30 people across channels; the Google Ads sub-team is the 8 of them who actually touch Google Ads.

If it's the same people with the same access, it doesn't need to be a sub-team — flat is fine.

Creating a Team or Sub-team

Both use the same modal. Select the parent (Organization or Team), click Create team:

Create Team modal with Name and optional Description fields and a Save action
The Create Team modal — two fields, one of them optional.
  • Name — required.
  • Description — optional, free text.

That's it. The new node appears under its parent in the tree, and selecting it shows an empty Members tab.

Choosing the right scope for roles

A role exists at exactly one node. People who hold the role at that node get its permissions for that scope.

  • A role on Organization applies workspace-wide. Use sparingly — typically only Owner and Admin-style roles live here.
  • A role on a Team applies to that team and (if the role is propagating) to its sub-teams.
  • A role on a Sub-team applies only there.

The propagating flag matters: a role that doesn't propagate stays at its node and doesn't apply to nested sub-teams; a propagating role flows down. See Roles for the full mechanic.

Editing and deleting

  • Edit — same modal, pre-filled. Change name or description.
  • Delete — recursive. All child nodes and their contents go too. See Organization tree for the full cascade.

Reports tab on a team

A team can be associated with a Client ID (set elsewhere — typically by an admin during initial setup). When that's the case and you have manage roles, the team detail panel exposes a third tab: Reports. This is intentionally separate from the global Reports section — it's narrowly about which reports for that client this team has access to. Most workspaces don't use this; configure it only when scoping per-team report access is necessary.