Troubleshoot common issues and get answers to frequently asked questions about the ServiceNow v8 integration.

📘

Looking for a Different Version?

The Troubleshooting Guide and FAQs for the v7 integration are also available.

Installation and Configuration

PagerDuty App Does Not Appear in the System Menu

1. If you’re having trouble finding the PagerDuty app in ServiceNow’s system menu, please check the following first:
   1. If you just installed the app, try a hard refresh in your browser, or log out/in again, as the left menu may need to reload after installation.
   2. Make sure the PagerDuty app has been added to your current instance from the ServiceNow store.
   3. Install the app to your current instance by going to System Applications Applications Downloads tab.
2. If you’ve completed the steps above and are still unable to see the PagerDuty app, check to see if you have any plugins that could prevent the installation from succeeding.
   1. For example, if you have installed a plugin that encrypts attachments in ServiceNow, we’ve seen cases where it looks like the installation completes when it has not actually done so. If you identify such a plugin, please try deactivating it and attempting installation again.

Installation and Configuration FAQs

How can I tell which version of the app I have installed?

How many accounts/instances can be connected?

Which configuration files are relevant to the integration?

Who should I reach out to if I have any questions about upgrading/installing/configuring the integration?

Integration Health Check

Cross-scope Access Policy Error During Webhook Async Processing Mode Setup

If you receive an error during the Setup webhook async processing mode step, the workaround is to:

1. Search on the menu for Scripts - Background.
2. Select scope Global.
3. Run the following script code: gs.invalidateCache();
4. Re-run the Integration Health Check (Select All and search and select Integration Health Check. It will run automatically).

Integration Health Check FAQs

What issues are detected by the integration health check?

Webhook Health Check

Webhook Health Check FAQs

What are some common issues detected by the webhook health check?

Which Webhook Health Check run is being referenced in the results?

Provisioning

When Assignment Group or Configuration Item Provisioning Fails

• Confirm that the object’s name does not conflict with an existing service or escalation policy in PagerDuty.
• Check that your PagerDuty account has user licenses available if there are new users being provisioned.

Provisioning FAQs

Are ServiceNow objects and PagerDuty objects mapped 1:1?

What is the difference between provisioned versus linked?

Data from PagerDuty to ServiceNow

PagerDuty Incidents are Not Creating/Updating Tickets in ServiceNow

Run the Integration Health Check

To run the Integration Health Check in ServiceNow, select All and search and select Integration Health Check. The health check will run automatically, and once it is complete, the results will be displayed on this page.

• We recommend running the Integration Health Check during the initial configuration of the PagerDuty app in ServiceNow, and also when upgrading the app to v8.

Run the Webhooks Health Check

Select All and search and select Webhooks Health Check. Click Run health check or Re-run health check to identify if there are any inconsistencies which may be causing this behavior.

Check if the Webhook Created a Webhook Import Row Record

In ServiceNow, select All and search and select Webhook Import Rows. Look for records with a creation time that coincides with when the PagerDuty incident was triggered, acknowledged or resolved.

Check Requirements and Restrictions in your ServiceNow Instance

1. Check to see if there are any required fields in the ServiceNow incident form that aren’t auto-populated via Inbound Field Rules: If you can see that webhooks are getting through from PagerDuty to ServiceNow, but are not creating or updating an incident, try manually closing an incident in ServiceNow. If manually closing an incident requires you to enter values for certain fields, your required fields have likely been customized. Create inbound field rules so that required fields have a default value.
2. Check for interfering state values: Check to see if you have any custom choices set up for the State field in the ServiceNow Incidents model:
   1. Right-click on the State field’s label (e.g., New or Resolved).
   2. Select Configure Dictionary.
   3. Switch to Advanced view.
   4. Select the Choices tab and look for entries with higher numbers in the Value field.

The integration follows the same convention as ServiceNow’s out-of-box state values. Higher numbers imply a more advanced state (i.e., 6 or higher represents done, resolved, or some variant). If the state of the incident that did not automatically resolve is a higher numeric value, but the incident did not resolve, it is because it was treated as already resolved.

To correct this, you may need to modify custom choice values for the State field to be lower than 6, so that they are treated as an unresolved state.

3. Check for customizations:

• Check for customizations to the configuration files.

  🚧

  Warning

  Please note that any customizations which alter the integration’s out-of-the-box behavior are not supported by the PagerDuty Support Team.

• Are there any modifications or customizations to the fields on the incident form?

4. Check for interfering data policies:
   Data policies allow ServiceNow administrators to create validation rules on tables. These data policies can stop the webhook import process from committing PagerDuty changes to the ServiceNow Incident record, and thus prevent the integration from automatically resolving incidents.
   When a data policy does this, there will not be any clear indication of it in the application-scoped logs. There will, however, be an error-level log entry in the system logs created at the time of the webhook import, with a message beginning that begins with Data Policy Exception.
   As of ServiceNow version 4, inbound field rules give you the ability to automatically fill incident fields, and this can be used to fill fields as needed in order to satisfy data policies.
   To address this:
   1. Navigate to System Policy Rules Data Policies.
   2. In the list view, create a new filter on the Table field: =incident.
   3. Make note of all the fields and constraints.
   4. Go to PagerDuty Configuration PagerDuty Inbound Field Rules.
   5. For each incident field that was part of the data policy’s conditions:
      1. Create a new inbound field rule.
      2. Set the webhook type to Acknowledge or Resolve, based on which action is experiencing an issue.
      3. Enter a default value for the field, or one dynamically based on the webhook payload.

For more information, please see Inbound Field Rules.

Check Requirements and Restrictions in Your PagerDuty Instance

1. Check that Assignment Groups match the Escalation Policy:

• If a ServiceNow Incident isn’t updating after changes happen on the corresponding PagerDuty incident, make sure the relevant PagerDuty escalation policy has a corresponding Assignment Group in ServiceNow.
• Ensure that the appropriate assignment group has its PagerDuty Escalation field set to the escalation policy’s ID (for example, PXXXXXX).
• You may need to add the two PagerDuty fields to the group form or list view to review their values.

Check PagerDuty Logs

To get the most detailed insight into script behavior, in ServiceNow go PagerDuty Configuration PagerDuty Settings and set Logging verbosity level to debug. With this setting selected, each call to gs.debug in the script source will show up in the application-scope logs, which can be viewed under PagerDuty Support Logs.

Duplicate Incidents Triggered in ServiceNow

• Coalesce was not set to true, meaning that any webhook originating from the same PagerDuty incident isn’t getting de-duplicated, and as a result, it’s creating new ServiceNow Incidents.

  • You may see this behavior if the import transform map is not set to coalesce on the incident ID. Verify that coalescing on the incident ID is enabled in the import transform map:
    • In ServiceNow, go to PagerDuty Import Rows Webhook Import Service.
      b. At the bottom of the page, select PagerDuty Webhook Import under Web Service Transform Maps.
    • At the bottom of this page, find the section Field Maps.
    • In the mapping for id x_pd_integration_incident, ensure that Coalesce is set to true.

• There may be instances where coalescing is true, but duplication is still occurring. Thus, we recommend trying to index the PagerDuty Incident ID field in the ServiceNow incident table incident.x_pd_integration_incident, so that coalescing on that column is more efficient.

PagerDuty Webhooks are Generating a 401 Error

A 401 server error indicates that the accessing user is unauthorized. If you use IP safelisting, make sure you have safelisted PagerDuty’s IPs in your production environment. You can use a tool such as Postman to test remote access.

Please read our developer documentation Webhook IPs for more information about the IPs addresses PagerDuty uses to send webhooks.

Data From ServiceNow to PagerDuty

ServiceNow Incidents and Updates do not Appear in PagerDuty

1. In ServiceNow, select All and search and select Integration Health Check to run the health check.
2. Check the Default user ID on the PagerDuty Settings page in ServiceNow:
   1. The Default user ID configuration property in the ServiceNow app needs to be a PagerDuty user ID.
   2. The PagerDuty user associated to this ID must be linked/mapped to a ServiceNow user.
   3. Their login email address in PagerDuty must match their email address in ServiceNow.

ServiceNow Sends Too Many Incident Emails or Worknote Updates

We’ve seen cases where ServiceNow sends hundreds, or even thousands of emails or worknote updates on an Incident. This is usually due to a feedback loop, which can result from ServiceNow custom business rules or automation. It is also possible to use webhooks to inadvertently create a feedback loop between ServiceNow and PagerDuty.

This can happen if there are any business rules or other automated processes that alter the Assignment Group of the ServiceNow incident, and caution is not exercised when manually setting the integration fields. To give a high-level example of how this can possibly happen, let us assume the following configuration:

• There is a business rule that automatically changes the Assignment Group to B if it is placed into Assignment Group A.
• Both Assignment Group A and B are tied to PagerDuty escalation policy Z.

A feedback loop occurs in the following scenario:

1. Incident changes the Assignment Group to, or is created in, B.
2. A PagerDuty incident triggers and is assigned to escalation policy Z.
3. A webhook fires and escalation restarts (webhook type incident.delegate or incident.trigger).
4. Webhook import in ServiceNow assigns incident to assignment group A.
5. Automation changes assignment to B.
6. The loop repeats.

If your configuration matches or is similar to the scenario described above, you’ll need to make adjustments so that the loop is broken.

ServiceNow Creates Duplicate PagerDuty Incidents

Assuming that there have been no customizations to the out-of-box PagerDuty integration, the most likely cause is automation. I.e., a separate business rule that is triggering a second automatic update on the incident record after the initial one. The business rule PD Trigger PagerDuty Incident runs with order = 100, meaning that it runs after changes are committed to the database. If two updates happen asynchronously in rapid succession, they risk triggering the business rule that creates a PagerDuty incident twice.

To resolve this, first you will need to find out how the secondary updates take place:

1. In ServiceNow, go to System Logs Events.
2. Find events named x_pd_integration.trigger_incident around the time duplicate incidents triggered.
3. Note the values of:
   1. param1, the last worknotes entry.
   2. param2, a comma-delimited list of extra parameters: current user sys_id, the operation (insert or update), and a boolean for whether the value of the Assignment Group or Configuration Item changed.
   3. User ID
   4. User name
4. Identify the event that was raised by the automated process based on how the event was submitted, vis-à-vis the available attributes.
5. Find some attributes of the automated update operation that can be used to distinguish it from others, e.g., if it was made by a human.
6. Add conditions to the business rule PD Trigger PagerDuty Incident that exclude updates which have the distinguishing characteristics of the automated updates.

Data from ServiceNow to PagerDuty FAQs

When is an incident sent to PagerDuty?

Business Rules

For more information about ServiceNow business rules, we recommend the following ServiceNow resources:

• Business Rules (Developer Documentation)
• Business Rules (Product Documentation)

Custom Fields

Custom Fields FAQs

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

Why can’t I edit the newly created PagerDuty Custom Field in ServiceNow after mapping?

I can't delete the custom field mapping

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

Can an admin disable or temporarily pause custom field syncing?

Are duplicate custom field mappings allowed?

Can the integration be modified to only sync data in one direction?

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

Inbound Field Rules

Inbound Field Rules not Filling Target Fields with Desired Values

A Business Rule or Process is Overwriting Field Changes

A business rule or some other process is overwriting the changes to the field after it is initially set by the field rule.

1. In ServiceNow, go to PagerDuty Configuration PagerDuty Inbound Field Rules and verify the following:
   1. For the inbound field rule in question, Enabled is true.
   2. The PagerDuty webhook type is the expected type.
2. Go to System Definition Business Rules and look for all rules that modify the field as follows:
   1. Enable the field Set field values in the list view.
   2. Search filter for table: =incident.
   3. Filter out all rows where Set field values is blank.
   4. If there is more than one page of results, search for all records where Set field values contains the column name, e.g., *business_service. If any results modify this field, it may explain why the field is not getting set according to the inbound field rule; check that the business rule is not overwriting the field.
   5. If nothing turns up, look at all business rules that run a script and check whether any scripts set the value of the field in question.

The Inbound Rule Only Applies to a Specific event type

Check if the inbound field rule event type matches the event type sent from PagerDuty.

The Inbound Field Rule is Inactive

Ensure that the inbound field rule is active.

New v3 Webhook Payload

Check if your inbound field rule is referencing a payload field that should be updated in order to reference the new v3 webhook payload.