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

# Teams

> The unit of responsibility that connects services to on-call schedules.

The team is the center of aciona.me's operating model. It connects two ends:

* On one side, the **services** the team answers for.
* On the other, the **on-call schedule** that says who gets paged at any moment.

```mermaid theme={null}
flowchart LR
  S1["Service: checkout"] --> T["Team: Platform"]
  S2["Service: payments-api"] --> T
  T --> E["On-call schedule"]
  E --> P["Person on call"]
```

## Create and edit

Owners and admins create teams under **Teams**. Each team has:

* **Name** — reflecting real responsibility, not the org chart.
* **Members** — who can join the schedule and act on the team's incidents.
* **Services** — what the team covers.
* **On-call schedule** — who answers right now.

## Choosing granularity

<AccordionGroup>
  <Accordion title="One team per on-call rotation" icon="repeat">
    The right question is not "which areas exist?" but "how many distinct on-call rotations will we actually maintain?". Each real rotation is a team.
  </Accordion>

  <Accordion title="Avoid teams without a schedule" icon="triangle-alert">
    A team without an active schedule resolves nobody. Incidents routed to it are created with no owner and fall back to the organization owners.
  </Accordion>

  <Accordion title="Avoid services without a team" icon="unlink">
    A service with no responsible team has the same effect. Review auto-registered services periodically.
  </Accordion>
</AccordionGroup>

## Deleting a team

Before deleting, move the team's services to another owner. Orphaned services produce ownerless incidents.

<Columns cols={2}>
  <Card title="Team members" icon="user-plus" horizontal href="/en/teams/members" />

  <Card title="On-call schedules" icon="calendar-clock" horizontal href="/en/on-call/schedules" />
</Columns>