PagerDuty User Management Guide

• Model type: hybrid
• Description: PagerDuty uses a base role system (Account Owner, Global Admin, Manager, Responder, Observer) applied account-wide, combined with Advanced Permissions (team-level roles and object-level roles) available on Business and Enterprise plans. Advanced Permissions allow users to have different roles on different teams, enabling granular access control without granting global privileges.
• Custom roles: Yes
• Custom roles plan: Business or Enterprise
• Granularity: Team-level and object-level (services, schedules, escalation policies) role assignments are possible under Advanced Permissions. Base roles apply globally. Custom roles allow defining specific permission sets beyond the standard role options.

1. Log in as Account Owner or Global Admin.
2. Navigate to People → Users in the top navigation.
3. Click 'Add Users' (or '+New User' depending on UI version).
4. Enter the user's name, email address, and select a role.
5. Optionally assign the user to one or more teams.
6. Click 'Add' or 'Save'. PagerDuty sends an invitation email to the specified address.
7. The user must accept the invitation and set a password (unless SSO is enforced).

Required fields: Full name, Email address, User role

Watch out for:

• Invitation emails expire; if a user does not accept within the expiry window, the invite must be resent.
• If SSO is enforced, users log in via the IdP and may not need to set a PagerDuty password, but the account must still be created in PagerDuty (or provisioned via SCIM).
• Adding a user immediately consumes a billable seat on paid plans regardless of whether the user has accepted the invitation.
• Email addresses must be unique across the PagerDuty account; duplicate emails are rejected.
• Users added without being assigned to a team will have account-wide visibility based on their base role.

• Can delete users: Yes
• Delete/deactivate behavior: PagerDuty supports both deleting and deactivating users. Deleting a user permanently removes them from the account. Deactivating a user suspends their access while retaining their profile and historical data. Deactivated users do not consume a billable seat. Deletion is irreversible; historical incident assignments referencing the deleted user may show the user as removed.

1. Navigate to People → Users.
2. Locate the user by name or email using the search/filter.
3. Click on the user's name to open their profile.
4. Click the gear/settings icon or 'Edit User'.
5. Select 'Deactivate User' from the options.
6. Confirm the deactivation in the dialog prompt.
7. The user's status changes to 'Deactivated' and they lose login access immediately.

Watch out for:

• A user who is the sole on-call responder on a schedule or escalation policy must be replaced before deactivation to avoid coverage gaps and missed alerts.
• The Account Owner cannot be deactivated or deleted without first transferring ownership to another user.
• Deactivated users can be reactivated by an admin, which will re-consume a billable seat.
• Deleting a user is permanent and cannot be undone; PagerDuty recommends deactivating rather than deleting to preserve audit history.
• SCIM-provisioned users deprovisioned via the IdP are deactivated in PagerDuty, not deleted, by default.

• Where to check usage: People → Users → filter by status (Active/Deactivated) to review current seat consumption. Account Owner can view billing details under Account Settings → Billing.
• How to identify unused seats: PagerDuty does not provide a native 'last login' report in the standard UI. Admins can use the Audit Trail (available on Business/Enterprise) or the REST API (GET /users endpoint with query parameters) to identify users who have not logged in recently. Deactivated users are visible in the Users list with a 'Deactivated' status badge.
• Billing notes: Seats are billed per active user per month. Deactivated users do not count toward the billable seat total. Stakeholder and Limited Stakeholder licenses are billed separately from full user seats. Annual contracts are common at enterprise scale; mid-cycle seat additions may be prorated. Seat reductions on annual contracts typically take effect at renewal. PagerDuty does not publicly list Stakeholder pricing; it is negotiated as part of the contract.

Deactivating a user does not automatically remove them from on-call schedules or escalation policies - admins must audit and reassign coverage manually before or after deactivation, or risk missed alerts. Observer and Stakeholder roles still consume paid seats or require separate license purchases, so read-only access is more expensive than most teams expect.

PagerDuty does not expose a native last-login report in the standard UI; identifying inactive users requires either the Audit Trail (Business/Enterprise only) or a REST API query against GET /users.

Practitioners consistently flag two friction points: attribute sync gaps and role assignment after SCIM provisioning. SCIM reliably handles user creation and deactivation, but profile attribute updates - name changes, phone numbers - do not reliably sync from the IdP after initial provisioning.

SCIM-created users are also assigned a default role that frequently does not match the intended role, requiring manual correction or custom attribute mapping.

A third recurring issue is the absence of bulk import via CSV; large-scale onboarding requires the REST API or SCIM, with no UI-based alternative.

Common complaints:

• Attribute updates (e.g., name, phone number) do not sync from the IdP after initial SCIM provisioning; only user creation and deactivation are reliably handled.
• Azure AD (Entra ID) MFA in combination with PagerDuty SSO requires specific configuration workarounds to avoid login loops.
• SCIM-created users are assigned a default role that may not match the intended role; role mapping via SCIM is limited and requires manual correction or custom attribute mapping.
• No native CSV import for bulk user creation; large-scale manual onboarding requires using the REST API or SCIM.
• Removing a user from on-call schedules and escalation policies is a manual process not triggered automatically by deactivation, leading to coverage gaps if admins forget.
• Observer and Stakeholder roles still consume seats or require separate license purchases, making read-only access more expensive than users expect.
• No built-in 'last login' report in the UI makes it difficult to identify inactive users without API scripting or third-party tooling.
• Domain-based auto-provisioning (whitelisting) is not supported; every user must be explicitly invited or provisioned via SCIM.

Every app in your incident response stack carries some offboarding overhead, but PagerDuty adds on-call coverage risk on top of the standard administrative cost - a deactivated user left on a schedule creates an alert gap with no automatic warning.

SCIM is the right choice if your organization is on Business or Enterprise, has SSO already configured, and needs automated lifecycle management across a large user base.

Manual management is viable for smaller teams or orgs on Professional plan where SCIM is unavailable, but the on-call schedule dependency check before every offboard adds non-trivial operational overhead. Teams that need granular, team-scoped roles without granting global admin access should evaluate Advanced Permissions before committing to a provisioning approach.

Bottom line

PagerDuty's manual user management is straightforward for day-to-day adds and role changes, but offboarding carries real operational risk: a deactivated user left on an on-call schedule creates an alert coverage gap with no automatic warning.

Every app in your stack has some version of this problem, but in PagerDuty the consequence is a missed incident page rather than a stale Slack channel.

Teams on Business or Enterprise should prioritize SCIM with IdP-driven deprovisioning to reduce that risk, while accepting that role assignments and attribute updates will still require periodic manual audits.