Team Hierarchy
Use parent Teams, sub-Teams, private branches, and inherited-setting placeholders safely
Team hierarchy lets workspace admins organize Teams into parent Teams and sub-Teams. Use it to mirror how work is owned, reviewed, and routed without turning Team membership into a product permission.
Team hierarchy does not inherit source, folder, artefact, baseline, Spec-Driven Development, review, or workspace permissions. Those permissions stay governed by their own access rules.
How hierarchy works
Each Team can have one direct parent Team. A parent can have multiple sub-Teams, and Integrity keeps Team routes stable when a Team is moved or un-nested.
| Rule | Behavior |
|---|---|
| Parent selection | Workspace admins can choose a parent when creating or editing a Team. |
| Stable routes | Moving a Team does not change its slug or URL. |
| Depth | Integrity validates hierarchy depth and blocks loops. |
| Default Team | The default Team cannot become a child Team. |
| Archive | Active parent Teams cannot be archived while active child Teams still depend on them. |
Create a sub-Team Admin
Open Teams settings
Open Workspace Settings -> Teams.
Start a new Team
Select New Team and enter the Team name.
Choose a parent
Use the parent selector to choose an accessible parent Team, or leave the Team at the root.
Review privacy and settings prompts
If the parent is private, Integrity keeps the child Team private. If future inherited settings would be affected, Integrity shows a review prompt.
Move or un-nest a Team Admin
- Open Workspace Settings -> Teams.
- Select the Team.
- Open General.
- Choose a new parent Team or No parent team.
- Confirm the prompt.
Moving or un-nesting keeps the Team slug, members, owners, logs, and route intact unless a membership or privacy rule blocks the change.
Membership rules
Sub-Team membership requires active parent membership:
- A person can be added to a child Team only after they belong to every active parent Team.
- Parent Team membership does not automatically add a person to child Teams.
- When adding a parent Team member, admins can choose to add that person to missing active child Teams.
- When moving a Team under a private parent, Integrity can preview affected subtree members and add the required parent memberships after explicit confirmation.
- When removing someone from a parent Team, Integrity can preview and clean up affected child-Team memberships after explicit confirmation.
These confirmation paths are deliberate. They keep the strict backend rules fail-closed while giving admins a clear way to complete safe hierarchy changes.
Private branches
Private Team branches stay display-safe:
- A public Team cannot stay under a private parent.
- A private parent cannot have active public descendants.
- Making a parent private can also make active public child Teams private after explicit confirmation.
- Unauthorized viewers do not see hidden private Team names, slugs, colors, members, parent labels, child labels, breadcrumbs, sidebar branches, logs, exports, or agent summaries.
- Admin non-members see only the redacted governance view allowed for private Teams.
If a Team or log row is hidden or redacted, do not infer that a private Team exists. Integrity only shows the hierarchy detail your current access allows.
Inherited settings
Hierarchy owns the inheritance contract for Team Issue workflow statuses, workflow automation, labels, and estimates. These settings report whether the current Team is inherited or custom and identify the source Team only when the viewer can access it. Resetting a local override to inherit is a reviewed operation because local definitions can be removed or remapped.
Team Cycles, Triage, recurring schedules, source access, Project Files, baselines, reviews, and workspace permissions do not inherit through this contract. Each Team owns its Cycle schedule independently.
Supported Issue settings may inherit. Permissions never inherit.
When a coding agent prepares a move or un-nest action, its preview includes the accessible membership, privacy, and inherited-setting effects. The server recomputes those effects when you confirm, so a stale hierarchy cannot apply from an old preview.
Logs and freshness
Team hierarchy changes write audit evidence for parent changes, un-nesting, visibility cascades, membership backfill, and child-membership cleanup. Team-specific events appear in the Team Audit log, while Workspace Audit stays focused on workspace-level events.
Hierarchy updates refresh Team lists, Team detail pages, sidebars, settings, logs, member candidates, and inherited-setting readers through realtime/cache invalidation. Realtime pings do not include private Team names or member detail.