# Sub-Teams

> Part of the NocoDB documentation (Product docs > Teams). Index of all pages: https://nocodb.com/llms.txt. Any docs page is available as Markdown by adding `.md` to its URL.

URL: https://nocodb.com/docs/product/collaboration/teams/sub-teams
Last updated: 2026-08-17

Nest teams up to four levels deep, and understand how roles flow upward while table, record and field permissions flow downward.

You can create teams within teams to match how your company is organized. For example, an "Engineering" team can have "Frontend" and "Backend" as sub-teams.

Sub-teams can be nested up to **4 levels deep**.

```
Engineering
├── Frontend
│   └── Design System
│       └── Icons              ← maximum depth
└── Backend
```

<img alt="image" src={__img0} placeholder="blur" />

## Create a sub-team

1. On the **Teams** page, click the **Actions** (three dots) menu next to the parent team.
2. Select **Create Sub-team**.
3. Enter a name for the sub-team.
4. Click **Create Team**.

<img alt="image" src={__img1} placeholder="blur" />
<img alt="image" src={__img2} placeholder="blur" />

Alternatively, click **New Team** and select a parent team from the **Parent team** dropdown. Enter a name for the team and click **Create Team**.

<img alt="image" src={__img3} placeholder="blur" />

## Move a team

You can move a team under a different parent, or make it a top-level team.

1. On the **Teams** page, click the **Actions** (three dots) menu next to the team.
2. Select **Move Team**.
3. Pick the new parent team, or choose no parent to make it top-level.
4. Confirm the move.

<img alt="image" src={__img4} placeholder="blur" />
<img alt="image" src={__img5} placeholder="blur" />

<Callout type="warning">
  Moving a team also moves all its sub-teams. The total depth after the move cannot exceed 4 levels.
</Callout>

## Members in sub-teams

Adding someone to a parent team does **not** automatically add them to its sub-teams. You manage each team's members separately.

When you open a team's details, you'll see:

* **Direct members** — people you added to this team
* **Inherited members** — people from parent teams above, shown for reference with a label indicating which team they belong to

<img alt="image" src={__img6} placeholder="blur" />

## How sub-teams affect permissions

| What                              | Direction | How it works                                                                 |
| --------------------------------- | --------- | ---------------------------------------------------------------------------- |
| Workspace & base roles            | Upward    | Parent team members automatically get their sub-team's roles                 |
| Table, record & field permissions | Downward  | Sub-team members are included by default; you can switch to "This team only" |

Sub-teams change how permissions work in two ways:

### 1. Workspace & base roles flow upward

When you give a sub-team a role on a workspace or base, members of the **parent team also get that role** automatically. This way, managers in the parent team can always see what their sub-teams have access to.

**Example:** The "Frontend" sub-team has **Editor** access to Workspace X.

| Person | Team                             | Access to Workspace X          |
| ------ | -------------------------------- | ------------------------------ |
| Alice  | Frontend                         | Editor                         |
| Bob    | Engineering (parent of Frontend) | Editor — gets it automatically |
| Carol  | Backend (sibling, not parent)    | No access                      |

<Callout type="info">
  This only works 

  **upward**

  . Parent team members get the sub-team's roles, but sub-team members do 

  **not**

   get the parent team's roles.
</Callout>

### 2. Table, record & field permissions flow downward

When you grant a team access using **"Specific users or teams"** in [table visibility](/docs/product/collaboration/table-permissions#table-visibility), [record permissions](/docs/product/collaboration/table-permissions#table-record-permissions), or [field permissions](/docs/product/collaboration/field-permissions), you can choose whether to include sub-team members or not.

After selecting a team, you'll see a segmented control next to the team name with two options:

| Option                    | Who gets access                                     |
| ------------------------- | --------------------------------------------------- |
| **This team**             | Only direct members of this team                    |
| **+ Sub-teams** (default) | Members of this team **and all sub-teams below it** |

<img alt="image" src={__img7} placeholder="blur" />

{/* ![Hierarchy scope toggle — include sub-teams](/img/v2/collaboration/teams/scope-toggle-with-descendants.png) */}

**Example:** The "Infrastructure" table is visible to the "Engineering" team.

With **"Include sub-teams"** (default):

| Person | Team                         | Can see "Infrastructure"? |
| ------ | ---------------------------- | ------------------------- |
| Alice  | Engineering                  | Yes                       |
| Bob    | Frontend (sub-team)          | Yes                       |
| Carol  | Design System (sub-sub-team) | Yes                       |
| Dave   | Marketing                    | No                        |

With **"This team only"**:

| Person | Team                         | Can see "Infrastructure"? |
| ------ | ---------------------------- | ------------------------- |
| Alice  | Engineering                  | Yes                       |
| Bob    | Frontend (sub-team)          | No                        |
| Carol  | Design System (sub-sub-team) | No                        |

This toggle is available wherever you see the **"Specific users or teams"** option:

* **Table visibility** — who can see a table
* **Record permissions** — who can create or delete records
* **Field permissions** — who can edit a field

---

## Related pages

- [Organization Teams](https://nocodb.com/docs/product/collaboration/teams/organization-teams.md): Organization-wide teams managed from the Admin Panel, assignable across any workspace in the org.