How to Change User Roles in PagerDuty (3 Methods)

A Global Admin role handed out during a midnight incident can outlive the incident, and an engineer who steps off the on-call rotation can keep a Manager role they no longer need. Neither one calls for deleting the account. PagerDuty user roles sit on up to three layers (base, team, and object), so one dropdown doesn’t always finish the job.

The role decides the bill too, because every PagerDuty role except the two Stakeholder roles takes a Full User license.

A complete role change touches the base role, any team and object roles, and the license. The right method depends on how many people change, and how often. PagerDuty’s own Users page fits a single person, Torii runs role changes off HR moves, and the REST API handles scripted or bulk edits.

How PagerDuty User Roles Work: Base, Team, and Object Roles

PagerDuty runs two role models, basic roles and Advanced Permissions, and the plan decides which one an account gets. Free accounts and the legacy Starter and Team plans use basic roles: Limited User, User, Admin, and Account Owner, plus a Stakeholder role that only paid plans can add. Advanced Permissions comes with Professional, the PD Reliability Platform plans, and the legacy Business, Digital Operations, and Enterprise for Incident Management plans. PagerDuty Support may have to switch it on.

Under Advanced Permissions the widest layer is the base role, and PagerDuty’s Advanced Permissions docs define it in one line: “Base roles establish the level of access a user has across the entire account.” There are eight base roles. Four are fixed (Account Owner, Global Admin, Full Stakeholder, Limited Stakeholder), so no team or object role can widen or narrow them. The four flexible roles (Manager, Responder, Observer, Restricted Access) can be adjusted. Restricted Access sees nothing at all until it gets a team or object role. Older guides still use the basic names, but on Advanced Permissions plans the old Admin is Global Admin and Limited User is Responder.

Team and object roles use three names: Observer, Responder, and Manager. A team role defaults from the base role, so a Responder starts as a team Responder and a Global Admin as a team Manager. Object roles attach to a single service, schedule, or escalation policy. Only a user with a flexible base role can hold one.

Before any downgrade, read how the same docs define Observer: “Can view objects but cannot make modifications. If you assign an Observer to an incident, they temporarily have Responder access to that incident only and can respond to or reassign it.” That fits an engineer who leaves a rotation but still needs to see services and incidents.

Who Can Change Each PagerDuty Role

PagerDuty permissions to change a role depend on the layer, as the table below sets out, and no role edit can reach the Account Owner. PagerDuty allows only one per account, and neither the REST API nor SAML can create it. Ownership moves by transfer at User Icon > Account Settings > Change Account Owner, to an active user, and the previous owner becomes an Admin. If the person is leaving the company, our guide to removing a user from PagerDuty covers the handover.

Source: PagerDuty Docs, Manage Users and Account Settings, checked November 2026.

How a Role Sets the License and the Bill

PagerDuty sorts licenses into two groups, Full User and Stakeholder, and a person’s role fixes which group their seat comes from. Per PagerDuty’s List Licenses API reference, a Stakeholder license allows only the Full Stakeholder and Limited Stakeholder roles, and every other role takes a Full User license. The User Roles page states that “Stakeholder licenses are not billed the same as full users.”

A full user on PagerDuty Professional lists at $25 per user per month billed monthly, or $21 billed annually (PagerDuty Plans & Pricing, checked November 2026). Stakeholder licenses have no public price. On month-to-month plans the user charge follows the highest count of full users the account has reached, this month or earlier, according to PagerDuty’s billing documentation. A downgrade to Stakeholder lowers the bill only after the account’s license count is reduced too. Team and schedule memberships cost nothing extra.

Use PagerDuty’s Users Page

The Users page reaches all three layers for one person. On Free accounts the whole job is a single Role dropdown under People > Users > Edit.

1. Confirm you hold Account Owner or Global Admin

Check the who-can-change table above: base and object roles need the Account Owner or a Global Admin.

2. Open People > Users and filter by Base Roles

Go to People > Users and use the Base Roles filter to see who holds Global Admin or Manager before you change anything. For a recurring check across the whole account, compare these ways to audit PagerDuty access.

3. Click Edit and choose the new base role

Click Edit in the Actions column next to the person, pick the new Base Role, and click Save.

4. Change the team role on Permissions & Teams or on the team’s page

An Account Owner, Global Admin, or Manager base role opens People > Users, clicks the person’s name, and picks a new Team Role on the Permissions & Teams tab. Team Managers have only one route, which PagerDuty’s Manage Users docs spell out: “Users with a Manager Team role are only able to edit a user’s Team role from their Team’s page.” That page is People > Teams > the team > Users tab, where a Team Role change asks for confirmation.

Flexible Licensing, a billing setup where PagerDuty manages licenses from the Users page list, is the exception: it removes role assignment from the user details page, so this route and step 5 may not offer it.

5. Adjust object roles under Additional Permissions

For a user with a flexible base role, open Permissions & Teams, click Edit next to Base Role, and go to Additional Permissions. Assign Manager, Responder, or Observer on a specific service, escalation policy, or schedule, then click Save.

6. Check the Full User and Stakeholder counts

The top of the Users page shows how many Full User and Stakeholder licenses are in use. Annual plans carry a separate limit for each, so moving a Stakeholder up to Responder can run into the Full User cap.

Use Torii to Change PagerDuty Roles When Someone Moves

Torii reads every PagerDuty user’s role, status, and license on each sync, and it changes the base role through a custom action that Torii documents in its help center.

1. Sign up for Torii

Start with Torii’s free two-week proof of concept to get the account PagerDuty connects to.

2. Connect PagerDuty with a read-write API key

In PagerDuty, a Global Admin or the Account Owner (Admin on basic-role accounts) creates a general access key at Integrations > API Access Keys > Create New API Key. Leave the Read-only box unchecked, since a read-only key syncs users but can’t change a role. Paste it into the PagerDuty tile on Torii’s Integrations page. A green checkbox appears once the sync finishes (Torii’s PagerDuty integration guide). Torii’s PagerDuty integration page lists what syncs.

3. View PagerDuty roles in Torii and automate the change

A role someone changes inside PagerDuty shows up in Torii on the next sync. Changing the role from Torii takes a workflow on the User attribute changed trigger, which fires for a mover, meaning an employee whose department, title, manager, location, or employment status changes (the mover step in these user provisioning tools).

Add a Custom action (HTTP Request) that sends a PUT to https://api.pagerduty.com/users/[USER ID] with the new role, name, and email in the body. The API key comes from Torii’s Secrets Vault, and Torii’s custom action guide for updating a PagerDuty user’s role lists the exact headers and body.

For the seat, the Change PagerDuty user license action moves a user between license types in the same workflow. Torii doesn’t set team or object roles. Add PagerDuty user to teams adds membership only, so those two layers stay in PagerDuty’s web app. Movers run next to joiners and leavers in Torii’s identity lifecycle automation.

Use the PagerDuty REST API

The REST API changes base and team roles with two PUT calls, though its role values don’t match the names in the web app.

1. Create an API key with write access

Account API keys come only from account administrators (the Account Owner or a Global Admin, or an Admin on basic-role accounts). User tokens exist only on Advanced Permissions accounts. A scoped OAuth app needs users.write for the base role and teams.write for team roles.

2. Check which roles the user’s license allows

Call GET /users/{id}/license before any write, because the response lists the license’s valid_roles and its role_group, either FullUser or Stakeholder.

3. Translate the role name to its API value

Map each role through the table above before you write, so Responder becomes limited_user, Manager becomes user, and Global Admin becomes admin. The values observer and restricted_access work only with Advanced Permissions. A user created through the API or SAML starts as Manager. Accounts provisioned through Okta, OneLogin, or Microsoft Entra ID carry the base role over SCIM (the standard identity providers use to sync users), with the same values as the REST API.

4. Send PUT /users/{id} with the new role

Send PUT https://api.pagerduty.com/users/{id} with a user object holding type, name, email, and the new role (headers are in the code below). A 200 returns the updated user and an invalid role value returns 400 (PagerDuty’s Update a user reference).

5. Set the team role with PUT /teams/{id}/users/{user_id}

This endpoint takes a body such as {"role": "responder"}, with observer, responder, or manager as the allowed values, and sets the member’s team role. It returns 204 on success and 402 when the account lacks the ability (PagerDuty’s term for a plan feature).

6. Set object roles in the web app

The REST reference has no object-role endpoint, so roles on a single service, schedule, or escalation policy go through step 5 of the Users page method.

# Needs curl and jq. Use a REST API key without the read-only restriction.
export PD_KEY="your-api-key"
export PD_USER="PXXXXXX"
H_AUTH="Authorization: Token token=$PD_KEY"
H_ACCEPT="Accept: application/vnd.pagerduty+json;version=2"

# 1. Which roles does the user's license allow? Look for valid_roles and role_group.
curl -s "https://api.pagerduty.com/users/$PD_USER/license" -H "$H_AUTH" -H "$H_ACCEPT" | jq .

# 2. Change the base role (Responder = limited_user). 200 = updated, 400 = invalid value.
curl -s -o /dev/null -w "%{http_code}\n" -X PUT "https://api.pagerduty.com/users/$PD_USER" \
  -H "$H_AUTH" -H "$H_ACCEPT" -H "Content-Type: application/json" \
  -d '{"user": {"type": "user", "name": "Jane Doe", "email": "jane@example.com", "role": "limited_user"}}'

# 3. Set the team role (observer, responder, or manager). 204 = done, 402 = account lacks the ability.
curl -s -o /dev/null -w "%{http_code}\n" -X PUT "https://api.pagerduty.com/teams/PTEAMID/users/$PD_USER" \
  -H "$H_AUTH" -H "$H_ACCEPT" -H "Content-Type: application/json" \
  -d '{"role": "responder"}'

Whichever method runs the base role, two things always end in PagerDuty’s web app: the Account Owner moves only by transfer, and object roles have no REST endpoint. After a batch of changes, the Base Roles filter on People > Users shows who still holds Global Admin or Manager. For the wider question of who should hold which role in every app, compare these user access review tools.