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

# Restrict incident type management to a team

> Let teams manage their own incident types and lifecycles

By default, editing incident types and lifecycles requires account-level permissions (**Manage incident types** and **Manage incident lifecycles**) that are usually only held by admins. That works well for smaller organizations, but it has two downsides as you grow:

* To let one team tweak the incident types they care about, you have to hand them a global permission that also lets them change everyone else's.
* Anyone with the permission can change any incident type, including making a sensitive team's incidents public, or removing the teams that automatically get visibility of them.

You can solve both by giving incident types (and lifecycles) an **owning team**, then granting the **Manage incident types** permission at the team level. Once you do, only the owning team can configure their own types and lifecycles, while everyone else is locked out. This guide will walk you through setting that up.

## Before you start

You'll need:

* **Teams set up in the catalog**, with the right people as members. See [Getting started with teams](/catalog/teams).
* **An admin to do the initial setup.** Assigning an owning team to an incident type or lifecycle requires the **Manage incident types** permission granted globally, so the first pass needs to be done by an admin.

The permissions you'll be working with are **Manage incident types** and **Manage incident lifecycles**. Both can be granted to a [team role](/admin/team-roles), so they only apply to the incident types and lifecycles a team owns.

## Step 1: Give your incident types an owning team

Head to **[Settings → Incident Types](https://app.incident.io/~/settings/incident-types)** and edit a type. In the **Incident type owner** field, choose the team (or teams) that should own it.

Once a type has an owning team, the people who can edit, delete, or override its forms are restricted to:

* Anyone with the **Manage incident types** permission granted globally (such as an admin)
* Members of an owning team who have the permission granted to that team

A type with no owning team stays as it is today: only people who hold the permission globally can manage it.

Lifecycles work the same way. Head to **[Settings → Respond → Lifecycle](https://app.incident.io/~/settings/lifecycle)**, edit a lifecycle, and set its **Lifecycle owner**. Once owned, only that team (or a global admin) can change its statuses, post-incident flow, and other configuration.

<Info>
  Your **default** lifecycle can't be owned by a team: it applies to every incident across your organization and changes to it always require the global permission.
</Info>

## Step 2: Create a team role with the permission

Go to **[Settings → Permissions](https://app.incident.io/~/settings/permissions)**, and on the **Team-level** tab create a team role (or edit an existing one), selecting **Manage incident types**. To let the same team manage their lifecycles, add **Manage incident lifecycles** too.

Assign this role to the members of each team who should be able to manage their own incident types. You can control who has which role from the **Members** tab of the team's page. See [Team roles](/admin/team-roles) for more on how this works.

## Step 3: Confirm it's working

Someone outside an owning team will see the edit, create, and delete buttons disabled, with a tooltip explaining they don't have permission for that incident type or lifecycle. Members of the owning team, and anyone who holds the permission globally, can manage it as normal.

## FAQs

<AccordionGroup>
  <Accordion title="Who can change which teams own an incident type?">
    Reassigning ownership always requires the **Manage incident types** permission granted globally. A team can manage
    the configuration of a type they own, but they can't hand it to another team or remove their own team from it. This
    stops a team from quietly giving away (or locking others out of) a shared type.
  </Accordion>

  <Accordion title="What happens to incident types with no owning team?">
    Nothing changes for them. They can only be managed by people who hold the **Manage incident types** permission
    globally, which is the same as how every incident type behaves today.
  </Accordion>

  <Accordion title="Can a type be owned by more than one team?">
    Yes. You can assign multiple owning teams, and a member of any one of them (with the permission granted to that
    team) can manage the type.
  </Accordion>

  <Accordion title="What about incident forms?">
    Form overrides for a team-owned incident type follow that type's owning teams, so only the owning team can override
    or edit them. Org-wide forms that aren't tied to a specific type still require the **Manage incident types**
    permission granted globally. See [Incident forms](/admin/incident-forms).
  </Accordion>

  <Accordion title="Can admins still manage every incident type and lifecycle?">
    Yes. Anyone who holds the permission globally can manage any incident type or lifecycle, regardless of which team
    owns it. This allows a small set of administrators to step in across teams.
  </Accordion>
</AccordionGroup>