You can map ServiceNow incident fields and PagerDuty custom fields that share the same data type. Once these fields are mapped, field values sync bidirectionally. The PagerDuty incident and ServiceNow incident must be linked for those fields to sync.

Custom fields created within ServiceNow count towards your account custom field limits. For more information, see custom fields on incidents.

📘
Prerequisite
You must configure the ServiceNow Integration to use this feature.
Custom field mappings and syncing are available on the Enterprise Incident Management plan. Contact our Sales Team to upgrade to a plan with this feature.

🚧
Required User Permissions

In ServiceNow: Only users with the x_pd_integration.admin role can view, create, and delete custom field mappings in ServiceNow.

In PagerDuty: Only Global Admins and the Account Owner can create, edit, and delete custom fields.

View Custom Field Mappings

You can only view custom field mappings in ServiceNow. To view your custom field mappings, navigate to PagerDuty Custom Field Mappings.

When viewing incident types in PagerDuty, custom fields mapped to a ServiceNow field display ServiceNow ITSM in the Managed By column.

Create Custom Field Mappings

🚧
Restrictions

Field mappings are one-to-one. A ServiceNow field can only map to one custom field, and a custom field can only map to one ServiceNow field. Once you map a field, it does not appear as an option when creating a new mapping.

The PagerDuty custom field data type must match the data type expected by the ServiceNow field.

You cannot map a read-only ServiceNow incident record field to a PagerDuty custom field.

A unique name is required for each incident type and custom field object.

The default synchronization direction for new mappings is bidirectional, but you can optionally change it to unidirectional. See the instructions in the following section.

In ServiceNow, navigate to PagerDuty Field Mapping Custom Field Mappings.
Click New in the upper right to create a new mapping.
Configure the mapping using the following fields on the screen:

Field	Value
ServiceNow field	Select your desired ServiceNow field from the dropdown menu. The integration only fetches ServiceNow fields that match the approved field types. If you choose to map a Choice field, you must create a new PagerDuty custom field to ensure consistent choice options across platforms.
Define Sync Direction	Select one of the following synchronization options: - Bidirectional: Custom field values sync bidirectionally between PagerDuty and ServiceNow. - Sync from ServiceNow to PagerDuty: Custom field values sync in one direction, from ServiceNow to PagerDuty. - Sync from PagerDuty to ServiceNow: Custom field values sync in one direction, from PagerDuty to ServiceNow.
PagerDuty Custom Field	Choose one of the following options: - Use an existing Custom Field: Select an existing field from the dropdown menu. Only custom fields with the same data type as the ServiceNow field appear. This option is not available when mapping a ServiceNow Choice field. - Create a new Custom Field: Configure the new PagerDuty custom field by entering the following details: - Display Name: Enter the name for the field when displayed in the PagerDuty incident UI. - Incident Type: Select the incident type that uses this custom field. The default selection is Base Incident. - Field Name: This field automatically populates with the display name. Refer to this field in the API by the field name. The field name can only contain letters, numbers, and underscores. - Description (optional): Enter a short description of the information this field displays in incidents. - Field Type: This field automatically populates with the type that matches the chosen ServiceNow field and you cannot change it.

Review the mapping and click Save. A modal appears indicating the field mapping was created successfully.

Edit Custom Field Mappings

At this time, you cannot edit field mappings. Once created, you must delete and then recreate custom field mappings to remap a field.

Delete Custom Field Mappings

You can delete the mapping between a ServiceNow field and a PagerDuty custom field. This action does not affect any field values already set on existing incidents and does not delete the fields. To delete a custom field in PagerDuty after removing a mapping, see custom fields on incidents.

❗️
Warning
This action cannot be undone. You can only delete mappings from ServiceNow.

In ServiceNow, navigate to PagerDuty Field Mapping Custom Field Mappings.
Select the record you want to delete.
Click Delete.
In the confirmation modal, click Delete again to confirm.

ServiceNow Fields Eligible for Mapping

Eligible Data Types

Choice (Choice, String with Choice Set, Integer with Choice Set) without dependent values.
- Note: Fields associated with choice sets of type “Suggestion” are treated as their underlying data type (String, Integer, and other base types), meaning they are not treated as choice fields.
Date Time (glide_date_time and due_date)
URL
String
Integer
Decimal
Boolean (True/False)

Eligible ServiceNow Incident Record Fields

The following bidirectional fields are available with version 8.0 or higher of our ServiceNow integration:

ServiceNow Field	Field Name	ServiceNow Type	PagerDuty Type
Active	active	True/False	Checkbox
Activity due	activity_due	Due Date	Date/Time
Actual end	work_end	Date/Time	Date/Time
Actual Start	work_start	Date/Time	Date/Time
Approval	approval	Choice (String)	Single Select
Approval set	approval_set	Date/Time	Date/Time
Business impact	business_impact	String	Text
Category	category	Choice (String)	Single Select
Child Incidents	child_incidents	Integer	Integer
Close code	close_code	Choice (String)	Single Select
Close notes	close_notes	String	Text
Closed	closed_at	Date/Time	Date/Time
Conference Bridge	x_pd_integration_conf_bridge	String	Text
Contact type	contact_type	Choice (String)	Single Select
Correlation display	correlation_display	String	Text
Correlation ID	correlation_id	String	Text
Description	description	String	Text
Due date	due_date	Date/Time	Date/Time
Expected start	expected_start	Date/Time	Date/Time
Follow up	follow_up	Date/Time	Date/Time
Impact	impact	Choice (Integer)	Single Select
Incident state	incident_state	Choice (Integer)	Single Select
Knowledge	knowledge	True/False	Checkbox
Notify	notify	Choice (Integer)	Single Select
Number	number	String	Text
On hold reason	hold_reason	Choice (Integer)	Single Select
Opened	opened_at	Date/Time	Date/Time
Order	order	Integer	Integer
Probably cause	cause	String	Text
Reassignment count	reassignment_count	Integer	Integer
Reopen count	reopen_count	Integer	Integer
Resolved	resolved_at	Date/Time	Date/Time
Severity	severity	Choice (Integer)	Single Select
Short description	short_description	String	Text
State	state	Choice (Integer)	Single Select
Upon approval	upon_approval	Choice (String)	Single Select
Upon reject	upon_reject	Choice (String)	Single Select
Urgency	urgency	Choice (Integer)	Single Select

The following fields are available with version 8.2 or higher of our ServiceNow integration. These fields are not bidirectional and only sync from ServiceNow to PagerDuty:

ServiceNow Field	Field Name	ServiceNow Type	PagerDuty Type
Assigned to	assigned_to	Reference	Text
Assignment group	assignment_group	Reference	Text
Business resolve time	business_stc	Integer (Read-only)	Integer
Caller	caller_id	Reference	Text
Caused by Change	caused_by	Reference	Text
Change Request	rfc	Reference	Text
Closed by	closed_by	Reference	Text
Company	company	Reference	Text
Configuration Item	cmdb_ci	Reference	Text
Contract	contract	Reference	Text
Delivery Plan	delivery_plan	Reference	Text
Delivery task	delivery_task	Reference	Text
Effective number	task_effective_number	String (Read-only)	Text
Last reopened by	reopened_by	Reference	Text
Last reopened at	reopened_time	Date/Time (Read-only)	Date/Time
Location	location	Reference	Text
Opened by	opened_by	Reference	Text
Parent	parent	Reference	Text
Parent Incident	parent_incident	Reference	Text
Problem	problem_id	Reference	Text
Resolve time	calendar_stc	Integer (Read-only)	Integer
Resolved by	resolved_by	Reference	Text
Service	business_service	Reference	Text
Service offering	service_offering	Reference	Text
Subcategory	subcategory	Choice (String) (Dependent)	Text
Transfer reason	route_reason	Choice (Integer) (Read-only)	Single Select
Universal Request	universal_request	Reference	Text

Custom Fields Unidirectional Sync

Custom field synchronization allows administrators to control the flow of data between ServiceNow and PagerDuty. When configuring custom field mappings, administrators can select from multiple synchronization options: bidirectional custom field data flow across both platforms, or unidirectional synchronization that restricts custom field data movement to a single direction. This flexibility allows organizations to implement synchronization strategies that align with their specific workflow requirements and data governance policies.

Select the Synchronization Direction

🚧
The default synchronization direction for new mappings is bidirectional.

ServiceNow administrators can define the synchronization direction when creating a new custom field mapping in the ServiceNow integration. This allows them to control the flow of data between PagerDuty and ServiceNow:

Bidirectional: Custom field values sync bidirectionally between PagerDuty and ServiceNow.
Sync from ServiceNow to PagerDuty: Custom field values sync in one direction, from ServiceNow to PagerDuty.
Sync from PagerDuty to ServiceNow: Custom field values sync in one direction, from PagerDuty to ServiceNow.

Update the Custom Field Sync Direction

Currently, the integration does not support modifying the sync direction once you save a custom field mapping.

However, you can delete the custom field mapping and recreate the mapping with your preferred sync direction.

View the Custom Field Mapping Sync Direction

When configuring a custom field mapping, you can refer to the directional arrow in the Review Mapping section, which indicates how data flows between the systems. Alternatively, you can navigate to the PagerDuty Custom Fields table and reference the Sync Direction column, which shows the sync direction for all custom field mappings in your ServiceNow environment.

Examples:

Supported ServiceNow Field Types and Mapping Restrictions

Three ServiceNow field types can sync unidirectionally to PagerDuty custom fields:

Reference field type
Read-only fields
Choice fields with a dependent field

More information regarding the ServiceNow field types and their mapping restrictions includes:

ServiceNow Field	PagerDuty Custom Field Type	Restrictions	Notes
Reference Fields	Text The integration uses `getDisplayValue()` to retrieve the value, which allows value transmission to the PagerDuty custom field in string (text) format.	Can only be synchronized in the ServiceNow PagerDuty direction.
Choices with a Dependent Field: Choice fields where the dependent field available values vary based on the parent field selected value.	Text The integration uses `getDisplayValue()` to retrieve the value, which allows value transmission to the PagerDuty custom field in string (text) format.	Can only be synchronized in the ServiceNow PagerDuty direction.	The value sent to PagerDuty is the label of the selected option. Options do not synchronize.
Read-Only Fields	Corresponds to the ServiceNow field type.	Can only be synchronized in the ServiceNow PagerDuty direction.	Notable exceptions: - ServiceNow Field Type: Choices with a Dependent field PagerDuty Custom Field Type: Text - ServiceNow Field Type: Reference PagerDuty Custom Field Type: Text

Identify Read-Only Fields

When configuring a custom field mapping, the Select a ServiceNow field section identifies read-only fields with the label Field type: . After selecting a read-only field, the Define the Sync Direction section displays an information message indicating that read-only fields can only sync one-way, from ServiceNow to PagerDuty.

Example:

Identify Choice Fields With a Dependent Field

When configuring a custom field mapping, choice fields with a dependent field are identified as follows: Field type: Choice (Dependent on . In the Define the Sync Direction section, you see an information message indicating that the dependent field type can only sync unidirectionally, from ServiceNow to PagerDuty.

Post-Mapping Behavior

The integration automatically posts custom field updates to the PagerDuty incident timeline. If you have custom field updates enabled in your incident activity stream, the integration also adds these updates to the ServiceNow incident work notes.

You can edit the custom field display name or the description within PagerDuty, but these changes do not immediately sync. Instead, the synchronization of custom field metadata—including the display name, description, and default value—is managed by the PagerDuty Custom Fields Support Script Include. This script runs automatically every hour. After the script executes, the custom field mapping list reflects the new display name or description.

Specific actions available in ServiceNow and explanations of how they function within the integration are outlined in the following sections.

Choice Field Updates

🚧
Restriction
You can only update choice field options within the ServiceNow Custom Field Mappings page; you cannot make these changes within PagerDuty.

When a ServiceNow choice field options change, the integration immediately updates the mapped PagerDuty custom field options. If you add, delete, or rename an option for the mapped ServiceNow field, the integration reflects this change in the custom field options in PagerDuty.

Data Type Updates

Editing the ServiceNow field data type can cause syncing issues, since the data type sent from the PagerDuty custom field no longer matches the data type expected by the ServiceNow field.

To avoid syncing issues, follow the process below:

Edit the ServiceNow field data type.
Disable the custom field in PagerDuty.
Create a new custom field in PagerDuty that matches the new data type.
Navigate to the PagerDuty custom field mappings table in ServiceNow.
Delete the mapping associated with the previous data type.
Create a new mapping from the new PagerDuty custom field to the ServiceNow field with the updated data type.

ServiceNow Field Label Updates

The integration does not sync field label updates to the Custom Fields Mapping table in ServiceNow. However, this does not impact the integration behavior - the integration continues to sync custom field values to that ServiceNow field despite using the original display name.

To resolve this, you can delete and recreate the field mapping.

Deleted ServiceNow Field

Deleting a ServiceNow field removes the field from all your ServiceNow incident records, along with its existing field values.

The deleted field is no longer available to new ServiceNow incidents, and the PagerDuty integration does not sync custom field values to a deleted ServiceNow field.

Deleting the ServiceNow field does not automatically remove the custom field mapping. You must manually delete the mapping from the Custom Field Mapping table within ServiceNow.

How Custom Fields Sync

Custom Fields Sync From PagerDuty to ServiceNow

Custom Fields Sync From ServiceNow to PagerDuty

Sync a Custom Field Mapping With a Default Value

ServiceNow fields can be configured with a default value within the dictionary entry. However, these default values do not automatically sync to PagerDuty. To ensure consistency, you must manually set the same default value in the corresponding PagerDuty custom field.

When you create a ServiceNow incident, the ServiceNow incident record field populates with the default value of the mapped PagerDuty custom field. This is a fast-follow action after the record is created, because custom field default values pass through via a v3 webhook event: incident.custom_field_values.updated.

Sync Fields Populated by Event Orchestration

Configuration: You can create the custom field mapping within ServiceNow. At this time, PagerDuty does not have features that allow you to map a new ServiceNow incident record field to an existing PagerDuty custom field.
Usage: When Event Orchestration populates the PagerDuty custom field, that value immediately syncs to the mapped ServiceNow incident record field. When you change the value of the ServiceNow incident record field, the value syncs back to the PagerDuty custom field. If the PagerDuty custom field populates with an invalid value that the integration does not recognize, that value does not sync to the ServiceNow incident record field.

Precedence

The latest value updated in either platform always takes precedence. You can change these fields even after an incident is resolved, in case you want to update information only discovered during your post-incident review process.

Troubleshooting Custom Fields

Error	Error Message	Cause	Action
`FIELD_DELETED`	The ServiceNow field used for this mapping was deleted in ServiceNow, or is no longer eligible for mapping	The ServiceNow field used for this mapping was deleted in ServiceNow, or is no longer eligible for mapping	- Delete this mapping - Create a new ServiceNow field - Create a custom field mapping for the newly-created ServiceNow field
`FIELD_TYPE_CHANGED`	The ServiceNow field type has changed and is no longer compatible with the current mapping	The ServiceNow field type has changed and is no longer compatible with the PagerDuty custom field type	- Delete this mapping - Create a new ServiceNow field with a field type that is compatible with the PagerDuty custom field type - Create a custom field mapping for the newly-created ServiceNow field
`REFERENCE_FIELD_ERROR`	You cannot update reference fields from PagerDuty	- The ServiceNow field was updated to a reference field, but its current sync direction is bidirectional. This results in an error because reference fields can only sync unidirectionally from ServiceNow to PagerDuty. - The ServiceNow field was updated to a reference field, but its current sync direction is PagerDuty to ServiceNow. This results in an error because reference fields can only sync unidirectionally from ServiceNow to PagerDuty.	- Delete this mapping - Create a new custom field mapping with a valid sync direction from ServiceNow to PagerDuty
`DEPENDENT_FIELD_ERROR`	You cannot update choices with a dependent field from PagerDuty	- The ServiceNow field was updated to a dependent field, but its current sync direction is bidirectional. This results in an error because dependent fields can only sync unidirectionally from ServiceNow to PagerDuty. - The ServiceNow field was updated to a dependent field, but its current sync direction is PagerDuty to ServiceNow. This results in an error because dependent fields can only sync unidirectionally from ServiceNow to PagerDuty.	- Delete this mapping - Create a new custom field mapping with a valid sync direction from ServiceNow to PagerDuty
`READONLY_FIELD_ERROR`	You cannot update read-only fields from PagerDuty	- The ServiceNow field was updated to a read-only field, but its current sync direction is bidirectional. This results in an error because read-only fields can only sync unidirectionally from ServiceNow to PagerDuty. - The ServiceNow field was updated to a read-only field, but its current sync direction is PagerDuty to ServiceNow. This results in an error because read-only fields can only sync unidirectionally from ServiceNow to PagerDuty.	- Delete this mapping - Create a new custom field mapping with a valid sync direction from ServiceNow to PagerDuty
`PD_FIELD_DISABLED`	The PagerDuty field used for this mapping is disabled in PagerDuty	The PagerDuty field used for this mapping is disabled in PagerDuty	- Re-enable the custom field in PagerDuty - Re-enable the custom field mapping in ServiceNow
`PD_FIELD_DELETED`	The PagerDuty field used for this mapping was deleted in PagerDuty	The PagerDuty field used for this mapping was deleted in PagerDuty	- Delete this mapping - Create a new custom field in PagerDuty - Create a custom field mapping for the newly-created PagerDuty field

If the error results from an incident.custom_field_values.updated webhook sent to ServiceNow, it appears in the incident work notes, provided that the Custom Fields errors option is enabled in your incident activity stream. This error also reflects in the custom field mapping record within ServiceNow.

If the error stems from the PagerDuty Custom Fields Support Script Include metadata synchronization job, it only appears in the custom field mapping record within ServiceNow and not in the incident work notes.

Examples:

FAQ

How do I create a new mapping if the “Custom Field limit in PagerDuty has been reached”?

Since you have reached the amount of custom fields available in your PagerDuty pricing plan, you must delete an existing PagerDuty custom field to free up a new creation. The mapping experience provisions a new PagerDuty custom field based on the ServiceNow incident record field chosen.

Can I edit/modify the PagerDuty Custom Field in ServiceNow?

To ensure configuration consistency, PagerDuty enforces that PagerDuty custom fields are only editable in PagerDuty. See our custom fields article for more information on how to edit an existing PagerDuty custom field.

Why can’t I edit the PagerDuty Custom Fields options for the Single Select or Multiple Select data type when it’s mapped to ServiceNow?

For the Single Select and Multiple Select data types, PagerDuty enforces that the ServiceNow incident record field is the source of truth for the options. Option edits and deletions in ServiceNow immediately reflect in the PagerDuty UI. Newly-added options in ServiceNow also sync back to PagerDuty until the maximum number of options for the PagerDuty custom field is reached. However, if a ServiceNow field has more options available than PagerDuty, options beyond that PagerDuty limit do not sync to the PagerDuty UI and the last selected option displays instead.

Can an admin disable or temporarily pause custom field syncing?

At this time, the integration does not provide features that allow administrators to temporarily pause custom field syncing.

Are duplicate custom field mappings allowed?

Field mappings are one-to-one. A ServiceNow field can only map to one custom field, and a custom field can only map to one ServiceNow field. Once you map a field, it does not appear as an option when creating a new mapping.

What is the expected behavior if multiple ServiceNow tickets are linked to the incident, or vice versa?

If multiple ServiceNow tickets link to one PagerDuty incident, or multiple PagerDuty incidents link to one ServiceNow ticket, the custom field value remains synced with the value of the more recent record.