Integration Background

When you change your PagerDuty subscription to an Operations Cloud SKU, the set of available PagerDuty licenses on your account changes. The ServiceNow integration stores the license to use for newly provisioned users in the system property x_pd_integration.default_user_license. This value does not automatically update when your SKU changes, and it remains pinned to the previously selected license ID.

If the old license ID is no longer valid on the account, ServiceNow-initiated user provisioning fails. This failure occurs even if you have sufficient license capacity on the new SKU. The PagerDuty settings page in ServiceNow can visually appear to show the correct license selected because the UI falls back to displaying another option while the stored system property remains stale.

✅

Important

To resolve this issue, you must re-select the correct license on the PagerDuty integration settings page or directly update the x_pd_integration.default_user_license system property to the new license ID after the SKU change.

You should perform these steps as part of your OpsCloud upgrade runbook, ideally before the first attempt to provision new users after the upgrade.

Confirm New License IDs

You must confirm the new license IDs available on your account. You can find these IDs using one of the following methods:

• View the licenses in the PagerDuty web app.
• Use the PagerDuty /licenses API endpoint.

Update Default User License

1. Open the PagerDuty integration settings page in ServiceNow.
2. Select the desired default user license for newly provisioned users.

   Note: You must re-select the license even if the UI appears to show the correct license.

3. Save your changes.

Verify System Property

1. Navigate to your ServiceNow system properties.
2. Confirm that the x_pd_integration.default_user_license property reflects the correct new license ID after saving.

   Note: This change only affects newly provisioned users. Users who are already provisioned under the previous license do not receive retroactive updates.

Check Additional Provisioning Paths

You must check any other provisioning paths that can carry a stale license reference, including:

• SSO and SCIM provisioning configurations, such as Okta and Azure AD, where a license type can be specified at user creation.
• Any custom scripts or API integrations that create users with an explicit license ID.