Nested teams
Coordinate multiple development teams by grouping them together within a single parent team. Use feature settings in the parent team to drive alignment throughout the group.
Overview
Nesting teams allows you to organize work in sensible units based on how teams work together. Cycles, statuses and labels and other concepts set in a parent team are inherited by its sub-teams, so that the group can operate both as individual units within each sub-team as well as a unified whole.
Basics
Nest existing teams under a parent team
To nest an existing team underneath another, go Settings > Teams > Danger Zone in the team you wish to nest and select another existing team as its parent. Taking this action requires admin permissions. To protect the privacy of private teams, a private parent team may have only private sub-teams.
Create a new nested team
When creating a new team, optionally designate it as nested under an existing team. To protect the privacy of private teams, a private parent team may have only private sub-teams.
Configure a nested team
Once you've designated one team as nested under another, a wizard will take you through any conflicts that need to be resolved to finalize nesting the teams. Common tasks presented by the wizard include normalizing statuses between parent and sub-team and resolving duplicate label conflicts.
Once you nest teams, verify that the settings of your nested and parent teams fit your needs. Settings like your GitHub PR automations should be verified to ensure they meet your expectations after nesting.
Parent team feature settings inherited by sub-teams
Certain settings from a parent team are enforced throughout all sub-teams. These include:
| Feature | Inheritance by sub-teams |
|---|---|
| Status | Sub-teams have identical statuses to their parent team |
| Membership | A member in a sub-team must also be a member of the parent team |
| Cycles | If a parent team has a cycles schedule defined, all sub-teams will inherit the same schedule. If the parent has no schedule then sub-teams may define their own schedule. When merging a sub-team cycle schedule with a parent's, past cycles remain untouched. The current and upcoming cycles of the sub-team update to the closest parent cycles. |
Parent team feature settings accessible to sub-teams
Sub-teams can benefit from other features in the parent team, while also having flexibility to set up further team features as best suits the context. Features of this type include:
| Feature | Use in sub-team |
|---|---|
| Labels | In the same way that an issue in a team can take a workspace or team label, sub-teams add another layer. An issue in a sub-team can take labels scoped to that sub-team, its parent team, or the workspace. |
| Templates | Sub-teams can have dedicated templates. Templates available for use in a parent team are also available in sub-teams. |
| Views | Sub-teams can have dedicated views. Issues in sub-teams are accessible in the views stored in their parent teams. |
Independent feature settings in sub-teams
Other features in sub-teams have no relation to the parent team. These include:
- General settings (timezone, estimates)
- Recurring issues
- Slack notifications
- GitHub automation
- Triage
Private teams and nesting
If a parent team is private, its sub-teams must also be private. If a parent team is public, its sub-teams may be public or private.
As with all private teams in Linear, a user can see private team-specific data only when they belong to the private team themselves.
As an example, given a private parent team A with private subteams B and C, a user belonging to A and C cannot see issues belonging to B, even if those issues are in a project or view shared with teams A and C. If there is a project shared between teams B and C, this user would only see issues belonging to team C in the project.