Sync Service Reassignment with ServiceNow
Bidirectionally sync incident reassignments between ServiceNow and PagerDuty
The Service Reassignment feature enables bidirectional sync between ServiceNow and PagerDuty when incidents are reassigned to different Configuration Items (CIs) in ServiceNow, and when incidents are reassigned to different services in PagerDuty. This ensures data consistency and accuracy across both platforms.
The feature allows you to reassign an incident to a different service if it becomes clear that incident ownership belongs to another team, or if it was attributed to a service in error. It also ensures that updates to the service assignment are synced between PagerDuty and ServiceNow.
Prerequisite
You must configure the ServiceNow Integration in order to use this feature.
Configure Service Reassignment
- In ServiceNow, navigate to the PagerDuty Settings page.
- Under the Activity stream customization section, you can check the Service Reassignment option to enable incident work notes related to service reassignment updates. This will allow you to view these updates in the ServiceNow incident activity stream.
Webhook Support
When a PagerDuty incident is assigned to a different service, the integration sends an incident.service_updated
webhook to update the corresponding incident record in ServiceNow.
You can mass-enable this event subscription for your existing v3 webhooks in ServiceNow by running a webhook health check. After the health check completes, click Auto resolve inconsistencies to auto-remediate your existing v3 webhooks to support the new incident.service_updated
event type.
Key Concepts
Mapped vs. Unmapped Services/CIs
- Mapped: A Configuration Item in ServiceNow is mapped if the CI is linked to a PagerDuty service. For a CI to be considered mapped, its Assignment Group must also be linked to a PagerDuty escalation policy.
- Unmapped: An unmapped Configuration Item does not have a linked service in PagerDuty, or an Assignment Group linked to a PagerDuty escalation policy.
Synchronizing CI and Service Reassignments
Overview
- There are no limits to the number of times a CI or PagerDuty service can be reassigned.
- You can reassign an incident to a different CI from the ServiceNow incident record, and then later reassign again from the PagerDuty incident.
Mapped to Mapped
ServiceNow to PagerDuty

When you reassign an incident from one mapped CI in ServiceNow to another mapped CI, the integration automatically updates the incident’s service in PagerDuty.
The PD Update Service Business Rule detects when the cmdb_ci
incident field is updated in ServiceNow, and then relays the incident details to the PagerDuty Script Include for processing. The updateService()
function within the PagerDuty Script Include will construct the request payload, and then make the PUT request to update the PagerDuty incident’s service assignment.
{
"incident": {
"type": "incident_reference",
"service": {
"id": "XXXXX",
"type": "service_reference"
}
}
}
PagerDuty to ServiceNow

When you reassign an incident from one mapped PagerDuty service to another mapped PagerDuty service, the integration will send an incident.service_updated
webhook event to update the Configuration Item field (e.g., cmdb_ci
field) in the corresponding ServiceNow incident.
Mapped to Unmapped
ServiceNow to PagerDuty

When you reassign an incident from a mapped CI in ServiceNow to an unmapped CI, no changes are made to the PagerDuty incident’s service. The PagerDuty incident retains its original service assignment.
The incidents do not become “unlinked”, so data will continue to synchronize to the corresponding PagerDuty incident.
PagerDuty to ServiceNow

When you reassign an incident from a mapped PagerDuty service to an unmapped service, no changes are made to the ServiceNow incident's Configuration Item. The ServiceNow incident retains its original CI reference.
If the updated service is missing a webhook connection to ServiceNow, then the integration will create a data_only
webhook so that the data from PagerDuty can continue to synchronize to the ServiceNow incident.
data_only
webhooks are only used to sync data from PagerDuty to ServiceNow when a PagerDuty incident is reassigned from a mapped service to an unmapped service — they are not used to create or trigger incidents.
Unmapped to Mapped
ServiceNow to PagerDuty

When you reassign an incident from an unmapped CI in ServiceNow to a mapped CI, a new incident will trigger in PagerDuty, and it will assign to the PagerDuty service linked to the updated ServiceNow CI.
PagerDuty to ServiceNow

When you reassign an incident from an unmapped service in PagerDuty to a mapped service, a new incident will be created in ServiceNow, and it will assign to the ServiceNow CI linked to the updated PagerDuty service.
Synchronize Assignment Group and Escalation Policy Reassignments
ServiceNow to PagerDuty
Assignment Group Reassignment:
a. Assignment Group is linked to a PagerDuty Escalation Policy: The PagerDuty incident delegates to the escalation policy associated with the updated Assignment Group.
b. Assignment Group is not linked to a PagerDuty Escalation Policy:
- Enabled: Resolves the PagerDuty incident if the ServiceNow incident is assigned to a group that doesn't exist in PagerDuty. The ServiceNow incident becomes “unlinked” and the PagerDuty incident status changes to Resolved. No changes are made to the PagerDuty incident’s escalation policy.
- Disabled: Resolves the PagerDuty incident if the ServiceNow incident is assigned to a group that doesn't exist in PagerDuty. No changes are made to the PagerDuty incident’s escalation policy.
PagerDuty to ServiceNow
Escalation Policy Reassignment:
a. Escalation Policy is linked to a ServiceNow Assignment Group: The ServiceNow incident is reassigned to the Assignment Group linked to the updated escalation policy.
b. Escalation Policy is not linked to a ServiceNow Assignment Group: No changes are made to the ServiceNow incident’s Assignment Group.
Updated 1 day ago