Sub-teams#

A team can contain other teams, so the structure in QAnswer can mirror the one you already have — a Developers team holding Backend and Front-end, each of those holding teams of its own. Nesting is not only cosmetic: it decides who reaches a shared resource, who can administer a team, and which settings apply.

Creating a sub-team#

There are two ways to create one:

• On the organisation’s Teams page, use the plus button on the row of the team that should become the parent. The new team is created underneath it.
• In the Add Team dialog, choose a parent team. Leaving the parent empty creates a top-level team.

Team admins get the same view for their own team under Sub-teams, showing the tree rooted at that team rather than at the organisation.

How access flows#

Sharing follows the tree in one direction only, and that direction is what makes nesting useful:

• Shares reach downwards. A resource shared with a team is available to that team and to every team beneath it. Share an assistant with Developers and the Backend and Front-end teams can use it too, without a second share.
• Membership counts upwards. Belonging to a sub-team makes you count as a member of its parent teams for the purpose of reaching what they share — which is the same rule seen from the member’s side.

Administration#

Administration flows the other way. An admin of a team administers every team below it, so a Developers admin can manage Backend and Front-end, add sub-teams to them, and edit their members — without being made an admin of each one. Being an organisation admin covers every team in the organisation, at any depth.

What each page lists#

Lists stay exact. A team’s users, assistants, providers and connectors are that team’s own — a page scoped to a team never folds in what its sub-teams hold, and never shows the members of its parent.

Settings and defaults#

Settings that can be set per team — the default model, whether a resource is active, which connectors are enabled — are resolved from the most specific level that has an opinion.

The order is: your personal setting, then the selected team, then each of its parent teams in turn, then the organisation, then the platform default.

So a default model set on Developers applies in Backend as well, until Backend sets one of its own — and switching a resource off in Backend leaves Developers untouched.

Moving a team#

A team can be moved under a different parent at any time, or promoted back to the top level. It takes its sub-teams with it, and access is re-evaluated against the new position immediately — so a team moved out of a branch stops reaching what that branch shares.

Rules and limits#

• Teams can be nested up to 10 levels deep.
• A team cannot be moved underneath one of its own sub-teams, which would detach the branch from the organisation.
• A parent and its sub-teams always belong to the same organisation; a team cannot be nested under one from elsewhere.
• Deleting a team that still has sub-teams is refused, so a branch is never orphaned by accident. Delete or move the sub-teams first, or ask for the whole branch to be removed.