# Teams Create Teams to customize information presented to specific users 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 and mobile 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 with their Team. > **Availability:** Teams are available on the following pricing plans: Business, Digital Operations (Legacy), and Enterprise for Incident Management. These plans support an unlimited number of Teams. > > Customers on Professional plans can create up to two Teams. > > [Contact our Sales Team](mailto:sales@pagerduty.com) to upgrade to a plan featuring Teams, or to increase your Team limit. > **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. Creating [schedules](/incident-management/schedules/schedule-basics#create-a-schedule) and [escalation policies](/incident-management/schedules/escalation-policies#create-an-escalation-policy) before creating a Team is recommended. When you add an escalation policy to a Team, the escalation policy's users and schedules are automatically assigned to your Team. Read [Team Association Behavior](#team-association-behavior) for more information. 1. In the PagerDuty web app, go to **People** → **Teams** and click **New Team**. 2. Enter a **Name** for the Team and _optionally_ add **[Tags](/account-admin/tagging)**. 3. Click **Save** to continue. 4. You are 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. > **Escalation Policy Association:** When you add an escalation policy to a Team, associated users, schedules, and services are automatically added to the Team, too. You may also _optionally_ add individual users to the Team if they are not on a selected escalation policy. 6. Click **Save**. ## Edit a Team 1. In the PagerDuty web app, navigate to **People** → **Teams**. 2. To the right of your desired Team, select → **Edit**. 3. Make your required edits to the Team's **Name**, **Escalation Policies**, **Users**, and/or **Tags** by searching and selecting them from their fields. To remove escalation policies, users, or tags, click to the left of the object. 4. Click **Save**. ### Edit Team Roles Read [Manage Users: Edit Team Roles](/account-admin/manage-users#edit-team-roles) for more information about editing users' Team roles. ### Manage Team Business Service Subscriptions See our section on [Subscribe Users and Teams to Business Services](/incident-management/services/business-services/subscription#subscribe-users-and-teams-to-business-services) for more information about managing Business Service subscriptions. ## Delete a Team 1. In the PagerDuty web app, navigate to **People** → **Teams**. 2. To the right of your desired Team, select → **Delete**. 3. A dialog appears that prompts 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. 4. Once you have performed these tasks, click **Delete Team**. > **Non-Reversible Action:** This is a non-reversible action and cannot be undone. ## Team Association Behavior Accounts with the [Advanced Permissions](/account-admin/advanced-permissions) feature can group PagerDuty objects (for example, 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 also determines a user's access level to Team objects based on their [Team role](/account-admin/advanced-permissions#team-roles). For example, a user who has a Responder role on a Team also becomes a Responder on the Team's associated escalation policies, schedules, and services. To maintain consistent access to Team objects, keep the following in mind: - If you add a user to an escalation policy or schedule, PagerDuty automatically adds the user to any associated Teams. > **Schedule Override Permissions:** Users added to a schedule via an [override](/incident-management/schedules/edit-schedules#create-overrides) do not inherit the Team's permissions. - [Create a schedule](/developer/api/reference/rest/schedules/create-schedule) and [Update a schedule](/developer/api/reference/rest/schedules/update-schedule) API: - Adding users to a schedule via API adds the users to any associated Teams. - Associating a Team with a schedule via API adds the schedule's users to the Team. - [Create an escalation policy](/developer/api/reference/rest/escalation-policies/create-escalation-policy) and [Update an escalation policy](/developer/api/reference/rest/escalation-policies/update-escalation-policy) API: Adding a user to an escalation policy adds 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:** 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. In the PagerDuty web app, navigate to **People** → **Users** and click the desired user's **name**. 2. Select the tab **Permissions & Teams** and click **Edit** in the section **Teams and Team Roles**. 3. On the modal that appears, search and select a primary team for the user. You may also remove the primary Team by clicking . ![A screenshot of the PagerDuty web app showing how to manage a user's primary Team](/images/kb/ff169189d107a06fc9f143bd8c8bcbaabd1cf19659082c2f53a96b5706199ff4-manage-primary-team.webp) *Manage primary team* 4. Click **Save**. You can now see the user's primary team in the **Teams & Team Roles** section. ![A screenshot of the PagerDuty web app showing a user's primary team on the user profile](/images/kb/2792b9d9e99cd976be046daf002bcde24b6cb5b0853f1f4d559037129073af07-manage-primary-teams-profile.webp) *Primary team on the user profile* ## Filter by Team The Team filter dropdown is available on most PagerDuty objects in the web app, such as the [Incidents page](/get-started/navigate-incidents-page), [Service Directory](/incident-management/services/service-directory), [Users](/account-admin/advanced-permissions), [Escalation Policies](/incident-management/schedules/escalation-policies), and [Insights](/incident-management/analytics/insights). To filter the UI by Team, in the 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 stays 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 only see users associated with the selected Team. Your filter selection does not impact the view that other users see in their accounts. > **Team Filtering Behavior:** Team filter results may vary between the Incidents list and Insights reports because each view evaluates Team associations differently. The Incidents list tracks every Team an incident has been associated with throughout its lifecycle; Insights and Analytics filter strictly by the Team currently associated with the incident’s service at report time. If a service was reassigned to a different Team after an incident triggered, the incident may appear under its original Team in the Incidents list but under the new Team in Insights. This is expected behavior. ## Team Privacy With [Advanced Permissions](/account-admin/advanced-permissions#team-privacy), 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. Global Admins and the Account Owner have access to all private Teams. When a Team is set to private, users who are _not_ part of that Team cannot: - View the Team's schedules, escalation policies, services, and incidents - View Event Orchestrations associated with the Team - Find the Team's service or escalation policy when creating a new incident - Find the Team's escalation policy when reassigning or adding responders to an incident - Find the Team when adding subscribers to an incident - Find the Team on the Team lens dropdown, on the **People** → **Teams** page, or on the profile page of a user associated with the Team Users who are _not_ part of that Team can still: - Find users associated with the private Team on the **People** → **Users** page - Find users on the private Team when creating, reassigning, adding responders, or adding subscribers to an incident - Find users on the private Team when creating a schedule override > **Team Privacy Exceptions:** Team privacy does not currently apply to the following pages or configuration objects: > > - [Incident Workflows](/ai-automation/automation/incident-workflows) > - Post-Incident Reviews > - 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**. ![A screenshot of the PagerDuty web app showing how to edit a Team's external visibility](/images/kb/45c7e2f77634f8ec64a296aa03fe3999128d5188f1652fb4eb64f95e8647a00c-edit-team-privacy.webp) *Team visibility* ## Respond to Incidents From Other Teams The Team that an incident is associated with is based on the [service](/incident-management/services/services-and-integrations#create-a-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 is still associated with the Network Operations Team. Any users who are assigned to the incident can 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 show up under **Assigned to** when viewing the incident in the web app, or **Assignees** in the REST API. However, they do not see the incident on their Incidents dashboard if filtering by My Teams. Any users who are _not_ assigned to the incident _AND_ who do not have access to respond to incidents associated with the Network Operations Team (for example, 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) cannot respond to the incident. With that in mind, 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 allows 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](/account-admin/api-access-keys#generate-a-user-token-rest-api-key) that match their user permissions. For example, a user with a **Manager** base role can create a personal API key that allows them to edit a schedule. However, they cannot add new users to the account because a Manager base role does not allow this. Global Admins and the Account Owner can create and manage [global API access keys](/account-admin/api-access-keys), which typically offer more API access than user-specific API keys.