The offboarding feature allows administrators to easily deprovision users from their associated incidents, escalation policies and schedules. When offboarding a user, a Global Admin or Account Owner can reconcile triggered and/or acknowledged incidents that were assigned to the offboarded user by reassigning them to their affiliated escalation policy or resolving them. Administrators can also review their associated escalation policies and schedules, sending notifications to the user’s Team Manager** that they need to be replaced by another user on those objects.

** If the user is not part of a team, Global Admins and the Account Owner will be notified to perform these actions.

🚧

Requirements

PagerDuty accounts with Advanced Permissions, which come standard with Business and Digital Operations plans, have access to the offboarding feature.

Configure Offboarding Settings

🚧

Required User Permissions

Account Owners can configure offboarding settings.

Users With Assigned Incidents Settings

Enable Incident Reassignment (Recommended)

The offboarding feature is set to Fail the removal of any user with assigned incidents by default. In order to take advantage of the incident reassignment capability, the Account Owner must change this setting.

To enable incident reassignment:

1. Navigate to User Icon Account Settings User Offboarding.
2. Under Choose how assigned incidents are handled, select Automatically restart the incidents on their escalation policy.

Disable Incident Reassignment

If you would not like incidents to be automatically reassigned to another user on the escalation policy of the incident, you can optionally choose to turn off this behavior.

🚧

Warning

By changing this configuration, you will be required to resolve any incidents from the user in order to offboard them, or you can manually reassign the incident to the user of your choice and then commence the offboarding flow.

To disable incident reassignment:

1. Navigate to User Icon Account Settings User Offboarding.
2. Select Fail the removal of any user with assigned incidents (default).

Gaps in Escalation Policies and Schedules Settings

When users are offboarded, they are detached from any escalation policies or schedules they were on, leaving a placeholder. An email notification about these gaps is sent so that impacted users can update the escalation policies or schedules accordingly. You may also configure who is notified about escalation policy and schedule gaps by following the instructions below:

1. Navigate to User Icon Account Settings User Offboarding.
2. Select settings under the following headers based on your preferences:

• If an escalation policy or schedule has a gap and is owned by a team, then:

  • Notify all team members that have the manager role (recommended)
  • Do not notify any team members

• If there are no managers on the team, or if the escalation policy/schedule is not affiliated with a team, then send the notification to:

  • All Global Admins and the Account Owner (default)
  • The Account Owner
  • The specific users listed here (at least one must be selected): Search and select at least one user.

Offboard a User

🚧

Required User Permissions

Global Admins and the Account Owner can offboard a user.

1. Navigate to People Users.
2. Search for and select the name of the user that you wish to offboard. Click Delete User on the right side of the user profile screen.
3. On the next screen, if the user has any open incidents assigned to them, you will need to select the incident checkbox(es) and either Reassign to EP or Resolve their incidents. We recommend reassigning these incidents to their associated escalation policy, which will send a notification to a different user on that escalation policy.

📘

Note

If you choose to reassign and the offboarded user is the only person on an escalation policy, the incident will be reassigned to the Account Owner.

If the user does not have any open incidents assigned to them, you will not see this screen and you can continue to step 4.

4. On the next screen, you will be able to review the user’s associated escalation policies and schedules. You may proactively remove the user from these objects yourself, or, if you click Next it will send an email notification to Team Managers assigned to those escalation policies and schedules that they need to be replaced by another user on these objects. Note: If the user is not associated with any Team, or if they are on a Team without an assigned Manager, this notification email will be sent to Global Admins and the Account Owner.
5. Once the above details have been reviewed, click Delete User. See our Post-Offboarding section below for more details on the post-offboarding flow for Team Managers (or Global Admins and the Account Owner, if not applicable).

Post-Offboarding

🚧

Required User Permissions

• Team Managers associated with the offboarded user will need to take actions in their PagerDuty account in the post-offboarding flow by default.
• However, if the user is not associated with any Team, or if they are on a Team without an assigned Manager, Global Admins and the Account Owner will receive these prompts and will need to take action.

Once the user has been offboarded by a Global Admin or Account Owner, the following changes will be visible in your PagerDuty account, prompting Team Managers (default) or Global Admins and Account Owners (see Required User Permissions callout, above) to take action:

• Any incidents formerly assigned to the offboarded user will now either be resolved or reassigned to a different user based on the selections made in the offboarding flow.
• The offboarded user will be stubbed on their formerly-associated escalation policies and schedules, and there will be notification banners that will instruct administrators (see Required User Permissions callout, above) to replace them with different users:

• Administrators may follow our instructions to replace users on escalation policies and schedules.
• Administrators (see Required User Permissions callout, above) will receive a notification email instructing them to replace them with other users on those objects.