You can give a user access to a Team’s objects by setting them as a Manager, Responder, or Observer on that Team. Depending on a user’s role, they’ll have that level of access on a Team’s objects (services, escalation policies, and schedules).
When determining whether a user should have access to an object, PagerDuty will look whether they are a member of the Team to which that object belongs, and use their Team role. If the object is not part of a Team, PagerDuty will apply the user’s account-wide role.
The Account Owner, Global Admins, and Managers on a Team can configure other users’ team roles.
The Account Owner, Global Admins, and Stakeholders cannot have their Team access configured. Account Owner and Admins will have manager access to the Team by default, and Stakeholders will be observers.
The Account Owner, Admins, and Team Managers can control a Team’s external visibility, which will determine whether non-Team members can see associated services, schedules, and escalation policies. If a user is not part of a Team, and that Team’s visibility is set to private, objects associated with that Team will be filtered out of the web UI for that user. The REST API reflects this, too, and will only return objects that a user is allowed to see.
Visibility restrictions will not apply to the Account Owner or Global Admins, who are able to view and administer all objects in the account.
More specific and granular permissions take precedence over less-specific permissions. The user’s status as a global administrator, and the team visibility settings, take precedence over all other permissions.
Whether a user has a specific level of permission to perform any given task on an object, i.e. create, edit or view a Service, Escalation Policy or Schedule, is determined by performing the following tests. The first applicable condition determines if the user has permission to perform the task:
- Is the user a global admin or account owner?
- Does the object belong to a team whose visibility setting is Private, and is the user not a member of it?
- Does the user have any specific object-level permissions for the action?
- If the object belongs to a team, is the user a member of the team, and what is their role on that team?
- What is the user’s default, account-wide role?
Example 1: a user can have the Responder role on a team, but be granted Observer access to a given service on that team whose incidents they should be able to observe, but not acknowledge or resolve, because object-level permissions have higher precedence than team-level permissions.
Example 2: a user’s default role could be observer, but they could be made a manager of a specific team, giving them stakeholder access to all other teams and their respective objects, but the ability to manage their own team.