Team roles allow you to give teams the ability to manage their own config (escalation paths, schedules, alert routes, and alert sources) without letting them make changes to a different team’s config. Each resource can be owned by different teams - for example, one alert route could be managed by Team A while another alert route is managed by Team B.
Team roles have a configurable set of permissions assigned to them, and you can configure multiple team roles (for example Members and Admins) so that you can give certain people on the team additional roles that you don’t give to all team members.
Team roles are in addition to account-level roles , so if someone has permission to manage something at the account level, they’ll be able to make changes even if they’re not on the team that owns it.
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 ).
Users can have multiple roles on a team, and if they do, they have the union of permissions across all their roles.
If your teams are controlled externally (for example via Linear, GitHub, the catalog importer, Terraform), then anyone who has permission to update teams in the external system will be able to control which users have team roles within incident.io
Example: Team-owned schedules
This example shows the steps needed to make it so that everyone on a team can set up schedule overrides but only the manager of the team can edit the schedule.
First, make sure that schedules are owned by the correct team:
Next, create new team roles for members and admins:
Lastly, you can view and control who has what roles on the Members tab of the team’s page:
Now all members of teams will be able to create overrides for schedules they’re on, but only admins of those teams will be able to make changes to the schedule (for example working hours, when shift handovers happen, etc). 
