User Role Tiers
PagerDuty has two tiers of user roles depending on your account's plan. To determine which tier your role belongs to, click the User Icon in the upper right of your account and select My Profile. If you see a tab that says Permissions & Teams, please continue to use this article for reference. If you only see the User Settings tab, please visit our article on User Roles.
Advanced Permissions allow you to specify the team-wide role that a user has on any given team, and also the level of access a user has to incidents and configuration objects (services, escalation policies, and schedules).
- Increased control and security — Teams will be able to decide who is allowed to respond to incidents and manage the configuration for their team. Individual users will also be able to create and manage their own personal API Access Keys.
- Prevent human error — By empowering teams to control who has access to their incidents and configuration, accidents that might interfere with a team’s process can be mitigated.
- Limit the visibility of sensitive information — Teams will be able to set themselves as “Private” if their incidents or configuration contain sensitive information.
Availability of Advanced Permissions
Advanced Permissions are available to customers on our Business and Digital Operations plans. Please contact our Sales Team if you would like to upgrade to a plan with this feature.
If you are already on a Business or Digital Operations plan but do not yet have advanced permissions enabled, contact PagerDuty Support to request enablement.
Otherwise, if advanced permissions are not available to you, you can still use Basic User Roles to control what level of access your users have in your PagerDuty account.
With advanced permissions, there are three different types of roles: base roles, team roles and object roles. Each role is unique and dictates what a user has access to.
All users in an account have a base role, and when a new user is added to an account, they must be assigned one. A base role indicates the default level of access a user has to incidents and configuration objects across the entire account.
Base roles can either be flexible or fixed. A fixed base role is a base role that cannot be granted more or less permissions via a team role or an object role. A flexible role is a base role that can be granted more or less permissions via a team role or an object role.
Each base role is described below with an indication if they are fixed or flexible in parenthesis:
- Account Owner — (fixed) Full access to create, update, and delete objects, including a user’s permissions. Account owners can also access the Billing page. This role can only be granted to one person on an account.
- Global Admin — (fixed) Full access to create, update, and delete objects, including a user’s permissions.
- Manager — (flexible) Full access to create, update, and delete objects and all of their configuration. Depending on an Account Owner or Global Admin's discretion, these roles may be given lower access levels for specific objects.
- Responder — (flexible) Can take action on incidents, create incidents for any team, and create overrides.
- Observer — (flexible) Can view objects, but cannot make any modifications. If an Observer is assigned an incident, they will temporarily have Responder access to that incident only, and can respond and reassign. Observers are able to trigger incidents from the PagerDuty Slack app.
- Full Stakeholder — (fixed) Can view objects, but cannot make any modifications. Cannot be assigned or respond to incidents.
- Limited Stakeholder — (fixed) Can only view and subscribe to the status dashboard, view and edit their own user profile, and cannot view any other parts of PagerDuty. For more information, please read our section on Limited Stakeholders.
- Restricted Access — (flexible) By default, they cannot view or edit any objects on the account until they are given a specific team or object role.
Here is a general list of actions to which each base role can take. For flexible roles, this table indicates the level of access each flexible base role has by default on an account before being given more or less permissions via a team or object role.
Required User Permissions
The list below is not exhaustive, and you can check the Required User Permissions callouts on each feature's article to find out what permissions are required.
|Restricted access||Observer||Responder||Manager||Limited Stakeholder||Full Stakeholder||Global Admin||Account Owner|
|Only has access to the status dashboard and their own user profile. Cannot view any other account objects.||✓|
|Subscribe to incidents||✓||✓||✓||✓||✓**||✓**||✓||✓|
|Create/delete personal REST API access keys/tokens matching permissions level||✓||✓||✓||✓||✓||✓||✓|
|Respond to incidents assigned to them||✓||✓||✓||✓||✓||✓|
|Be added on schedules and escalation policies||✓||✓||✓||✓||✓||✓|
|View all public teams, services, schedules, escalation policies, analytics and postmortems across the entire account||✓||✓||✓||✓||✓||✓||View alerts from services that they have access to in the Alerts table. (Permission to view services may be restricted by Team and/or Object roles.)||✓||✓||✓||✓||✓||✓|
|Trigger and respond to incidents for any team||✓||✓||✓||✓|
|Create/delete overrides on any schedule||✓||✓||✓||✓|
|Create custom incident actions||✓||✓||✓||✓||✓|
∙ On-call schedules
∙ Schedule overrides
∙ Escalation policies
∙ Maintenance windows
∙ Response plays
∙ Business Services
∙ Business Services on incidents
|View/edit/delete all private teams and their services, schedules, and escalation policies across the entire account||✓||✓|
|Create/delete global API access keys||✓||✓|
|∙ Manage users
∙ Add new users
∙ Delete users
∙ Edit users’ profiles and passwords
∙ Configure users' base roles, team roles, and object roles
∙ Redact Incidents
∙ Administer the account
∙ Change the account owner
∙ Edit billing information
∙ Add/edit/delete single sign on (SSO) properties
∙ Delete the account
∙ Change pricing plans
** Limited Stakeholder and Full Stakeholder subscriptions to incidents are only available on our new Business plan and Digital Operations plan. Please contact our Sales Team if you would like to upgrade to a plan with this feature.
To find your base role, click the User Icon, select My Profile, and then select the Permissions & Teams tab.
Team Responder Base Role (Legacy)
The Team Responder base role was deprecated as of 4/26/19. All users with this role have now been changed to a base account role of observer and their team roles will stay the same.
When a user is added to a team, they will also be given a team role. A user’s team role indicates the level of access that they have on that specific team. There are three different types of team roles:
- Observer — Can only view the configuration objects and incidents associated with that team. If an Observer is assigned an incident, they will temporarily have Responder access to that incident only, and can respond and reassign.
- Responder — Everything an observer team role can do, PLUS they can respond to incidents associated with that team, trigger incidents for that team, and create/delete overrides on any schedules associated with that team.
- Manager — Everything a responder team role can do, PLUS they can add/edit/delete schedules, escalation policies, services and service maintenance windows associated with that team. They can also add existing users to their team, as well as edit and delete their team.
When a user is added to or associated with a team for the first time, their default team role will be dependent on their base role. Users can be added to a team manually or automatically by being added to an escalation policy that is associated with a team.
Default Team Role When Added to a Team
** Users with flexible base roles (Restricted Access, Observer, Responder, Manager) can have their default team roles changed to grant them more more or less permissions on a specific team.
To find your team role, click the User Icon, select My Profile and then select the Permissions & Teams tab. Users may also have a primary team, which some organizations may need for billing purposes. Please read our section Manage Primary Team for more information.
Objects roles are specific levels of access given for specific configuration objects (a schedule, escalation policy, and/or service) to an individual user. There are three types of object roles: Observer, Responder, and Manager.
Can view and add notes to incidents triggered on this service
Can view schedules and create/delete overrides
Can view and respond to incidents triggered on this service
Can edit schedule and create/delete overrides
Can edit, set maintenance windows, and respond to incidents triggered on this service
To find your object-level role(s), click the User Icon, select My Profile and then select the Permissions & Teams tab.
Base roles establish the level of access that a user has to everything across the entire account, whereas team and object roles gives users more or less access to specific configuration objects and incidents than what they would have access to at the account, or base role, level.
Base, team, and object roles can be managed by different users on the account based on their level of permissions.
Manager (team role)
Manager (base role)
Global Admin (base role)
Account Owner (base role)
Can modify team roles of users on their team
Can modify team roles for any user on any team
Can modify base roles for any user
Can modify object roles for any user
Users with an Account Owner or Global Admin base role can update other users’ base roles.
To update a user’s base role, go to the Permissions & Teams tab on their user profile and click Edit next to their Base Role.
Users with an Account Owner, Global Admin, or Manager base role can update other users’ team roles. Users with a Manager team role can also update the team roles of users, but only for users on their team.
Users with an Account Owner, Global Admin, or Manager base role can update a user’s team role from the user’s profile page. Go to the Permissions & Teams tab on the user’s profile and select their team role from the drop-down menu under Teams & Team Roles.
Users with a Manager team role are only able to update a user’s team role from their team’s page. Navigate to the People menu and select Teams, then click on your Team, select the Users tab and then select the appropriate role under the Team Role column for that user.
If a user is not yet part of a team, please visit our section on manually adding users to a team.
Users with an Account Owner or Global Admin base role can update other users’ object roles. Note that object roles can only be given to users with a flexible base role (i.e. Restricted Access, Observer, Responder, Manager).
To update a user’s base role, go to the Permissions & Teams tab on their user profile and click Edit next to their Base Role.
Under Additional Permissions, assign an object role to a specific schedule, escalation policy, and/or service.
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:
Will NOT Be Able To
WILL Be Able To
Note: Team privacy does not currently apply to the following pages or configuration objects:
- Response plays
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.
To update a team’s privacy, navigate to the People menu, select Teams and then click on your desired Team. Navigate to the Users tab on that team’s page and set the External Visibility to either public or private.
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 UI, 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 either 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
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 the base role of Manager 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.
When an account migrates from Basic to Advanced Permissions, most basic user roles are automatically mapped to advanced permissions base roles.
Please note there is not an Observer role on Basic Permissions.
When provisioning a user through the REST API or SAML, the user will by default be given the Manager (a.k.a. User) role, unless specified in the user's
role property. The value set for it must be one of a set of fixed values that is recognized by our internal APIs, or our web services will respond with status
400 Invalid Request.
The values of the
role field of user records, and also the permissions system, are as follows:
Flexible or Fixed
Manager / User
Account Owner **
** Cannot be created through API / SAML
For more information on Advanced Permissions best practices, please visit our Community post.
Updated about a month ago