---
title: "Teams"
description: "A team is Incident Management's top-level ownership unit — every schedule, escalation policy, and incident belongs to exactly one team."
---

A **team** is the top-level ownership unit in Incident Management. Every [schedule](/monitoring/incident-management/schedules), every [escalation policy](/monitoring/incident-management/policies), and every incident belongs to exactly one team — there is no cross-team or org-wide incident, by design. A small organization might run everything through a single "Default Team"; a larger one splits by service, product, or on-call rotation.

## Membership and roles

A user becomes a team member with an `im_team_member.imRole` of either:

- **`member`** — can be scheduled, paged, and assigned to incidents owned by the team.
- **`admin`** (team admin) — additionally may edit the team, and create/edit/delete its schedules, escalation policies, alert sources, and routing rules.

Team-admin is scoped to that one team — it does not grant org-wide write access. An organization-level `admin` role always has full write access to every team, without needing team membership at all.

## Write access

Mutating a team or its membership requires one of:

- the organization's own `admin` role, or
- a global admin (cross-org support access), or
- a user who is themselves a team admin **of that specific team**.

The same bar applies to creating a schedule, escalation policy, alert source, or routing rule under a team: org-admin, or admin of that team.

## Analytics

A team has an `analyticsEnabled` flag ("Enable analytics") that turns on response/resolution metric tracking (MTTA/MTTR) for that team. It defaults to off for a new team.

## API

See [Teams](/api/incident-management/teams) for the public read endpoint.