> ## Documentation Index
> Fetch the complete documentation index at: https://docs.warrn.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Teams

> Teams are how Warrn knows who owns what. Every service, on-call schedule, and alert ends up belonging to a team.

## Why teams matter

Almost everything in Warrn is anchored to a team. When an alert fires, Warrn looks at the service it came from, finds the team that owns that service, and uses the team's on-call schedule and settings to decide who gets paged.

```
Organization
└── Team
    ├── Members         who is on this team
    ├── On-call         who is reachable when
    ├── Services        what this team runs
    │   └── Alerts      what's going wrong on a service
    └── Knowledge       runbooks and docs the team owns
```

Most orgs run one team per ownership group: "platform", "billing", "growth", an SRE team. How many teams you can create depends on your plan.

## Creating a team

Go to **Teams** in the sidebar and click **New team**. You need the **admin** role on your organization to create one. A team needs a name and an optional description.

## Roles

| Role       | What they can do                                                                                                                                |
| ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| **Admin**  | Edit the team. Add and remove members. Create and delete services owned by this team. Acts as the fallback on-call if no schedule is set.       |
| **Member** | View everything in the team. Acknowledge and resolve alerts. Take part in incident response. Cannot edit team settings or remove other members. |

A team can have many admins. We recommend at least two so settings are never blocked by a single person being out.

## What lives on a team

* **[On-call](/components/teams/on-call)** - schedules, rotations, escalation policies, and overrides.
* **[Alert intelligence](/components/teams/alert-intelligence)** - AI Triage, Auto-Group, and past-alerts lookback.
* **[Integrations](/components/teams/integrations)** - alert sources, Slack, Jira, Confluence, etc. attached at the team level.
* **[Knowledge](/components/knowledge)** - runbooks and notes that belong across the whole team. Services have their own knowledge trees for things specific to one service.

## Deleting a team

Admins can delete a team from its detail page. Services owned by the team become orphaned and need to be reassigned to keep alerts routing. Members stay in the organization. On-call schedules are deleted. Past alerts and incidents stay in the system for history.

<Tip>
  If you're not sure whether to delete or rename, rename first. Deletion is irreversible.
</Tip>