# Team administration

Manage teams, their members and the permissions they inherit.

The **Teams** page manages groups of people in your organization. A team can give its members shared permissions and act as a reviewer target for [escalation paths](/docs/web-app/escalation-paths).

These are separate choices. Permissions determine what members can do. Routing determines which requests reach the team, and its [escalation policy](/docs/web-app/teams) determines who is notified and when.

## Teams

The team list shows each team's name, permissions, member count and escalation-policy status. Search matches team names and permissions. **Live teams**, **Archived teams** and **All teams** control which records appear. A **Directory** badge identifies a team managed through your identity provider.

A new team starts with a name, no members and no permissions. Creating it does not route requests to it. Renaming a team keeps its membership, permissions and routing references intact.

![Teams inventory showing Payments review demo, its member count, permissions and escalation-policy status](/images/docs/team-administration/inventory-light.png)

The inventory brings membership, permissions and escalation-policy status together.

## Members

A team's **Members** section shows its roster. People added manually are selected from active members of the organization. Adding someone to a team does not invite a new person to the organization, and removing someone from a team does not remove their organization membership.

[Membership management](/docs/web-app/membership-management) covers inviting people to the organization, suspension and removal.

Membership affects both inherited access and review routing. When someone joins, they inherit the team's permissions. When they leave, they lose access supplied by that team, while keeping their direct permissions and access from other teams.

An escalation path targets the team rather than a fixed copy of its roster. Current membership determines who belongs to that target, including for pending requests. Members still need permission to review or decide those requests.

If the team's active escalation policy names someone individually, removing them from the team may be blocked. An updated active policy must stop naming that person before the app can remove their membership.

![Payments review demo showing its member roster, no inherited permissions and no escalation policy](/images/docs/team-administration/team-light.png)

A team can have members without granting them additional permissions.

## Permissions

The team's **Permissions** section shows the access every member inherits. A permission policy combines the actions members can perform with the **Scope** where they apply. The [Permissions guide](/docs/web-app/permissions) covers assigning access, ownership and decisions outside routing.

| Scope | Where the permissions apply |
| --- | --- |
| Organization | Throughout the organization, including future resources. |
| Teams | Only to the teams selected in **Applies to**. |
| Agents | Only to the agents selected in **Applies to**. |

The available permissions depend on the scope. Request-review permissions use the Organization scope; routing still determines which requests each member may decide. Permission to manage a team does not by itself allow its members to approve requests.

Saving a permission policy changes the team's access. Members combine that access with their own permissions and those inherited from other teams. Removing a permission policy removes only the access it supplied.

```mermaid
flowchart TD
    direct["Direct permissions"] --> access["Member's combined permissions"]
    team["This team's permissions"] --> access
    other["Other teams' permissions"] --> access
```

### Example: A refund-review team

We'll use **Payments review demo** to group the people who handle refunds. Our team can give them permission to read and decide requests, while an escalation path routes refund requests to the team. When staffing changes, the roster changes without replacing the team in every path.

![Team permission editor showing Organization scope and available request permissions, with none selected](/images/docs/team-administration/permissions-light.png)

A permission policy defines both actions and scope. This example form is unsaved; the documentation team has no permission grants.

## Escalation policy

A team's escalation policy controls notification order when a request reaches it. The list shows an active revision, **No active revision**, or **No policy**. Without an active policy, every eligible member is notified at once.

The policy does not grant approval permission or limit decisions to the members it notifies. Authorized current members of the targeted team can review before their notification step. One approval or denial ends the request.

The [Teams escalation-policy guide](/docs/web-app/teams) covers notification rules, independent timers, saved revisions and activation. The [Review queue guide](/docs/web-app/review-queue) explains reviewing and claiming requests.

## Directory membership

Directory-managed teams get their names and synced members from your identity provider through [Directory sync](/docs/web-app/directory-sync). Those names and memberships are maintained there. The app does not allow these teams to be renamed or archived manually.

Manual members can be added alongside directory members. A person may belong through both sources. Removing their manual membership does not remove a directory membership; the **Directory** badge explains why they remain on the roster.

Directory membership and permission policies have different jobs. Sync keeps the roster current; the team's permission policies define the access that roster inherits.

## Archiving

**Archive team** permanently retires the team. Its roster and escalation-policy history remain available as read-only records under **Archived teams**, but the team no longer grants access or receives requests. Its permissions are revoked and its active escalation policy is deactivated. The team cannot be restored.

Archiving is blocked while an active escalation path or a pending request still targets the team. Removing a team from the current path does not change requests already routed with an earlier revision; those requests must finish before the team can be archived.

**Archive policy** is different: it keeps the team in use and returns new requests to the default of notifying everyone. It does not archive the team or remove its permissions.

## Access and history

Viewing teams, changing their details, managing membership and granting permissions require different access. Editing and activating a team's escalation policy are separate permissions too. Access can be limited to particular teams; creating a new team requires organization-wide team-management access.

You can grant only permissions you hold within a scope where you are allowed to manage access. If a permission is unavailable, the editor explains the restriction.

Team creation, membership changes, permission changes and archiving are recorded in [Audit log](/docs/web-app/audit-log). The [Teams API reference](/docs/reference/teams) covers managing teams from an integration.