Teams allow users to group and control user access to associated PagerDuty objects, such as escalation policies, users, schedules and services. They also allow users to customize the PagerDuty web app by filtering for information relevant to their Team’s associated objects. For example, a Security Team member may only want to see the users, incidents, schedules and services associated with the Security Team's escalation policies.

📘

Pricing Plan

Teams are available on the following pricing plans: Business, Digital Operations (legacy) and Enterprise for Incident Management. Please contact our Sales Team if you would like to upgrade to a plan featuring Teams.

Team Association Behavior

With Advanced Permissions, PagerDuty objects such as users, schedules, services and escalation policies may be grouped by their Team associations. When an escalation policy is added to a Team, the users, schedules and services associated with that escalation policy are also added to that Team. Furthermore, if any such objects have a Team association, then PagerDuty users will derive their permissions for those related objects through their Team role. So, for example, a user who has a Responder role on a Team will also become a Responder on the Team's associated escalation policies, schedules and services.

For this behavior to apply the correct permissions and not create any unwanted side effects, there are a few implicit changes that may occur when modifying PagerDuty objects:

• Users added to an escalation policy or schedule will be automatically added to those objects’ associated Teams.
• Schedules Update or Create API: Adding users to a schedule via API will add the users to any associated Teams.
• Schedules Update or Create API: Associating a Team with a schedule via API will add the schedule’s users to the Team.
• Escalation Policy Update or Create API: Adding a user to an escalation policy will add the user to any associated Teams. Such members may not be removed from the Team if they are still associated with an escalation policy that the Team is associated with.

Create a Team

🚧

Required User Permissions

Manager, Global Admin or Account Owner base roles can create Teams.

📘

Note

• You can add up to 100 unique escalation policies per team.
• There is a limit of 500 users per Team.
• Users can be on multiple Teams, but escalation policies can only be associated with one Team.

We recommend that you create schedules and escalation policies before creating a Team. When you add an escalation policy to a Team, the escalation policy's users and schedules will be automatically assigned to your Team. Please read Team Association Behavior (above) for more information.

1. Go to People Teams and click New Team.
2. Enter a Name for the Team and optionally add Tags. Click Save to continue.
3. You will then be directed to the Team’s details page. Click Edit Team on the right.
4. Search and select the Escalation Policies or Users that you would like to add to this Team.
   • Note: When you add an escalation policy to a Team, the users, schedules and services associated with it will be automatically added to the Team. You may also optionally select individual Users to associate with the Team if they are not on the escalation policies you selected.
5. Click Save.

Edit or Delete Teams

🚧

Required User Permissions

Manager, Global Admin or Account Owner roles can edit or delete Teams.

1. Navigate to People Teams and click the to the right of the Team name.

• If you are editing a Team: Select Edit from the dropdown. You may edit the Name by entering a new name. You may also edit Escalation Policies, Users and Tags by searching and selecting them from their fields. To remove escalation policies, users or tags, click the x to the left of the object. When you are finished editing, click Save.
• If you are deleting a Team: Select Delete from the dropdown. A dialog will appear that will prompt you to Edit Rulesets, Escalation Policies, Services and Schedules and Reassign Incidents associated with the Team, with the option to reassign incidents to another team via the dropdown. Once you have performed these tasks, click Delete Team.

Edit Team Roles

Please read Manage Users: Edit Team Roles for more information.

Manage Team Business Service Subscriptions

Please see our section on Subscribing Teams to Business Services.

Manage Primary Team

🚧

Required User Permissions

Global Admin or Account Owner roles can manage Primary Teams.

📘

Note

A user must already be a Team member of the selected primary Team. You may add users to a new Team or add a user to an existing team through the Teams page to select a primary Team that the user is not already on.

Some organizations may want users to have primary teams for billing purposes. To designate a user's primary team:

1. Navigate to People, select Users and click the name of the desired user.
2. Select the Permissions & Teams tab and click the Manage primary team button in the Teams & Team Roles section.
3. On the next screen you will have the option to search and select the user's desired primary team, or you may remove one by clicking the Unset primary team button. Click Confirm Selection to save.

4. You will now be able to see the user's primary team in the Teams & Team Roles section.

Filter by Team

The Team filter dropdown is available on most PagerDuty objects in the web app, such as the Incidents page, Service Directory, Users, Escalation Policies, Insights, etc.

• To filter the UI by Team in PagerDuty, click the Team drop-down. You can choose to view All Teams, My Teams, or select specific Team(s).
• When you select a Team filter on one page, the filter will persist as you navigate to other pages. For example, to quickly see all users in a Team, go to the Team drop-down menu and select your preferred Team, and then go to People Users. You will see that only users associated with the selected Team will appear.
• Your filter selection will not impact the view that other users see in their accounts.

Team Privacy

With Advanced Permissions, Teams have the option to be set to Private or Public. By default, all Teams are public.

• Public: Teams can be viewed and accessed by users outside of those Teams.
• Private: Teams cannot be viewed and accessed by users outside of those Teams, except for users with Global Admin or Account Owner base roles (these users have access to all private Teams).

When a Team is set to private, users who are not part of that Team:

Note: Team privacy does not currently apply to the following pages or configuration objects:

• Response Plays
• Postmortems
• Analytics

📘

Known Issues

Depending on the method used, there are some known inconsistencies related to incidents' visibility when a service is added to a private Team.

Method 1 (Recommended): If an admin changes a service's existing Team's visibility from public to private, incidents associated with the private Team's service and escalation policy will only be available to members of the private Team, Global Admin users, and the Account Owner (i.e., privileged users). This is the expected behavior.

Method 2: If an admin changes a service's existing, public Team to a different, private Team, the old Team's incident permissions will govern the visibility of historical incidents. This has the effect that already existing incidents will remain visible to non-privileged users on the Incidents overview page, as well as on incidents' detail pages.

Method 3: If an admin associates a service, which currently does not have a Team, with a private Team, historical incidents will be visible to non-privileged users on the Incidents overview page, however they will not be able to view incident details.

Edit Team Privacy

🚧

Required User Permissions

• Users with an Account Owner, Global Admin, or Manager base role can set a Team to public or private.
• Users with a Manager Team role specific to a Team can also set that Team to public or private.

1. To edit a Team’s privacy, navigate to People Teams and then select your desired Team.
2. Navigate to the Users tab on that Team’s page and set the External Visibility to either Public or Private.

Respond to Incidents From Other Teams

The Team that an incident is associated with is based on the service where the incident was triggered. For example, if an incident is triggered on a service associated with the Network Operations Team, then the incident is associated with the Network Operations Team. If the incident is reassigned to an escalation policy or user that belongs to a different Team, then the incident will still be associated with the Network Operations Team.

At this point, any users who are assigned to the incident will be able to respond to it, even if they are not associated with the Network Operations Team.* However, they won’t see the incident on their Incidents dashboard if filtering by My Teams. Any users who are not assigned to the incident AND who don’t have access to respond to incidents associated with the Network Operations team** will not be able to respond to the incident.

* These users must be directly assigned to the incident to take action on it. They should show up under Assigned to when viewing the incident in the web app, or Assignees in the REST API.

** A user with an Observer or Restricted Access base role and no Team role or object role specified for the Network Operations Team or its objects.

With that being said, if there is a user who needs to be able to respond to incidents for all or multiple teams, make sure that the user has any of the following:

• A Responder base role. This will allow them to respond to incidents associated with any Team.
• A Responder or Manager role on any Team for which they need to respond to incidents.
• A Responder or Manager object role on any service for which they need to respond to incidents.

Rest API Access

All users can create personal REST API keys or tokens on the User Icon My Profile User Settings page of their user profile. Keys or tokens created this way will provide access to the REST API that matches the user’s permissions.

For example, a user with a Manager base role can create a personal API key that will allow them to edit a schedule. However, they will not be able to add new users to the account because their level of access dictates that they cannot do this.

Global API access keys (which can be either full access or read-only) can be created and managed by users with a Global Admin or Account Owner base role.