Permissions allow you great flexibility in determining what objects (Services, Escalation Policies, and Schedules) users have access to. It can be daunting getting started, though, and this article is meant to go over some best practices and give some example use cases.
In following with the principle of least privilege, best practices dictate that you should only grant users as much access as they need to be effective in their role. In practice, this means you’ll typically want to limit the number of users with a Global Admins or Manager role, especially at larger organizations. For responders, a common pattern is to set the lowest access level as the base role, Observer, and grant additional permissions with great access as needed.
A few Examples
Fixed roles: Every PagerDuty account has one Account Owner, who has full access to everything in the account. Global Admins have mostly the same privileges as the Account Owner, the one difference being that only the Account Owner has access to the Account Settings menu, where billing info, for example, lives. You’ll most likely want to limit the number of Global Admins, since they have so much power.
Flexible roles: Flexible roles are where Permissions get “interesting,” since they start with a base role (Observer, Team Responder, Responder, or Manager), and a Global Admin or the Account Owner can assign additional permissions to various objects in the account.
Someone in a managerial role will most likely need to access schedules and escalation policies, and would be granted a “Manager” base permission. Since “Managers” can create, update, and delete all objects in the account, no additional permissions are required.
For someone who is more involved in the day-to-day of responding to incidents, it might make sense to give them an “Observer” base permission (view all objects, but unable to take any action), and grant them Manager or Responder access, for example, to the objects where they need more agency.
If you’ve already spent some time organizing users into teams, a solution may be to set users’ base permission to “Team Responder”. This access level allows responders to take action on incidents, create overrides, and set maintenance windows for objects belonging to their teams, and there shouldn’t be an immediate need to set any additional permissions (unless you’d like a user to have some agency on an object outside of their team).