The Teams feature allows you to group and control user access to associated PagerDuty objects, such as escalation policies, users, schedules, and services. This feature also allows for a customized view in the PagerDuty web app that only displays information related to a user’s Team. As an example, security engineers may only want to see users, incidents, schedules and services associated associated with their Team.

📘

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.

🚧

Required User Permissions

• Manager, Global Admin or Account Owner base roles can create, edit, and delete Teams.
• Global Admin or Account Owner roles can manage Primary Teams.
• 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 can also set the Team’s visibility to public or private.

Create a Team

📘

Product Limits

• 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.
  • Users can be on up to 400 Teams.

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.
3. Click Save to continue.
4. You will be directed to the Team’s details page. Click Edit Team on the right.
5. 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, associated users, schedules and services will be automatically added to the Team, too. You may also optionally add individual users to the Team if they are not on a selected the escalation policy.
6. Click Save.

Edit or Delete Teams

1. Navigate to People Teams and click the to the right of your desired Team.
2. 
   

• 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 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 Subscribe Users and Teams to Business Services.

Team Association Behavior

Accounts with the Advanced Permissions feature can group PagerDuty objects (e.g., users, schedules, services, and escalation policies) by associating them with a Team. When an escalation policy is added to a Team, the users, schedules and services associated with that escalation policy are also added to the Team. PagerDuty will also determine a user’s access level to Team objects based on their Team role. 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.

In order to maintain consistent access to Team objects, please keep the following in mind:

• If you add a user to an escalation policy or schedule, PagerDuty will automatically add the user to any associated Teams. Note: Users added to a schedule via an override will not inherent the Team's permissions.
• Create a scheduleand Update a schedule API:
  • Adding users to a schedule via API will add the users to any associated Teams.
  • Associating a Team with a schedule via API will add the schedule’s users to the Team.
• Create an escalation policy and Update and escalation policy API: Adding a user to an escalation policy will add the user to any associated Teams. Users may not be removed from the Team if they are still on an escalation policy that is associated with the Team.

Manage Primary Team

📘

Tip

In order to set a user’s primary Team, they must already be a member of the Team.

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

1. Navigate to People Users and click the name of the desired user.
2. Select the Permissions & Teams tab and click Manage primary team 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 Unset primary team. 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 web app click the Team dropdown. 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 stay in effect as you navigate to other pages. For example, to quickly see all users in a Team, go to the Team dropdown menu and select your preferred Team, and then go to People Users. You will only see users associated with the selected Team.

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:

• Incident Workflows
• 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

1. To edit a Team’s privacy, navigate to People Teams and select your desired Team.
2. Navigate to the Users tab on the Team’s page and set 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.

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. These users must be directly assigned to the incident to take action on it. They will show up under Assigned to when viewing the incident in the web app, or Assignees in the REST API. 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 (e.g., a user with an Observer or Restricted Access base role and no Team role or object role on the Network Operations Team or its associated objects) will not be able to respond to the incident.

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 role configurations:

• 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 that matches their user 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 access level does not allow this.

Global Admins and the Account Owner can create and manage global API access keys, which typically offer more API access than user-specific API keys.