Team roles

Team roles let you give teams the ability to manage their own config without letting them change another team’s. Each resource can be owned by a different team: one alert route could be managed by Team A while another is managed by Team B. This page covers how team-based permissions work in general. For the specifics of each resource, see:

• Alerts and escalations — resolving alerts and responding to escalations
• Incident types and lifecycles
• Workflows
• Announcements — a team’s announcement rules and post templates

Escalation paths, schedules, alert routes, alert sources, and API keys work the same way.

​

How team-based permissions work

Giving a team control of its own resources follows the same shape wherever you do it:

1. Give the resource an owning team. Where you set this depends on the resource (see the pages linked above). A resource with no owning team behaves as it did before you started. See Team resources for what ownership means.
2. Create a team role with the permission. At Settings → Permissions → Team-level, create a team role (or edit an existing one) and select the relevant permission.
3. Remove the account-level default, if the permission is granted to everyone. Some permissions (like Manage workflows or Manage announcements) are in the Standard base role out of the box, so everyone holds them account-wide. Until you remove that grant at Settings → Permissions → Account-level, team ownership has no effect on who can manage the resource.
4. Confirm it’s working. Someone outside an owning team sees the relevant controls disabled, with a tooltip explaining they don’t have permission for that resource. Members of the owning team, and anyone who holds the permission account-wide, can manage it as normal.

​

Assigning team roles

Who has which team role is controlled via the catalog. Each team role corresponds to an attribute on your Team catalog type (you can configure which catalog type represents your teams here). You can view and change who has which role from the Members tab of the team’s page. You can configure multiple team roles (for example Members and Admins) so that some people on a team get additional permissions the rest don’t. Users can hold multiple roles on a team, and if they do, they get the union of permissions across all of them.

​

Example: team-owned schedules

Say you want everyone on a team to create schedule overrides, but only the team’s managers to edit the schedule itself. First, make sure the schedule is owned by the right team: Then create two team roles, one for members and one for admins, each granting the schedule permissions that group should have: Assign those roles on the team’s Members tab, as above. Now everyone on the team can create overrides for schedules they’re on, but only the admins can change the schedule itself, like working hours and when shift handovers happen.

​

FAQs