- If you just installed the app, try a hard refresh in your browser, or log out and back in again, as the left menu may just not have been reloaded after the install process. This is the most common issue.
- Make sure the PagerDuty app has been added to your current instance from the [ServiceNow store] (store.servicenow.com).
- Install the app to your current instance by going to System Applications, selecting Applications, and clicking the Downloads tab.
Check to see if you have any plugins that could prevent the installation from succeeding. We've seen one instance where a customer had a plugin installed that tried to encrypt each attachment within ServiceNow, which lead to the install process of the PagerDuty app looking like it succeeded but in reality it failed, so they couldn't find PagerDuty in the left-hand navigation menu.
ServiceNow incidents do not trigger PagerDuty incidents, or updates to the incident in ServiceNow don't translate to PagerDuty
- Check that the REST API connection by going to PagerDuty → Configuration → Test REST API Connection. Check that the conditions for triggering are met.
- Check your main ServiceNow app settings, under PagerDuty → Configuration → Properties. Is auto-provisioning disabled? If so, then check to see what the value is in the field Default PagerDuty User ID to use if auto-provisioning is disabled.
- See “When is an incident sent to PagerDuty?”, in our ServiceNow integration FAQ page.
Default PagerDuty User ID
The "Default PagerDuty User ID" configuration property in the ServiceNow app needs to be a PagerDuty ID, rather than an email address or ServiceNow user ID. PagerDuty IDs are upper case alphanumeric strings that begin with
P (see: Where do the special PagerDuty field values come from?).
There should be only one user that has the given PagerDuty user ID in your ServiceNow instance, and the email address of that user should match the user with that ID in PagerDuty. Otherwise, some of the API calls that the integration needs to make may not succeed.
This value is used when making the REST API requests to create incidents in PagerDuty, if auto-provisioning is disabled. Thus, if it is set improperly, the requests may not succeed.
Most synchronization of data and events from PagerDuty to ServiceNow happens through webhooks sent from PagerDuty to ServiceNow. For this reason, if you notice incidents are not updating or getting created from PagerDuty, the webhook import process is what will need to be examined.
To test all settings, go to PagerDuty → Configuration → Test ServiceNow User Authentication. You should see the message:
x_pd_integration (PagerDutyTest): ServiceNow user authentication test successful (200)
If you see the following instead:
x_pd_integration (PagerDutyTest): ServiceNow user authentication test failed (403)
- Ensure that the ServiceNow user for authentication and ServiceNow password for authentication configured in PagerDuty → Configuration → Properties are valid credentials for a ServiceNow web service access user
- Ensure that the password is consistent between the user and the setting in the PagerDuty Configuration properties.
- Ensure that the user for webhook authentication has the following roles:
If the password or username have changed in ServiceNow, you must also update the credentials in the ServiceNow extensions on your PagerDuty services. Alternately, in all versions 3.5 and later, you can delete the extensions, set the value of the PagerDuty Webhook field to blank in your provisioned assignment groups and configuration items, and then re-provision them.
Check that the URL in the extensions is correct. The host it points to should be the same subdomain of ServiceNow as the one that you have integrated with PagerDuty.
If you have provisioned your services and webhooks in PagerDuty from a development or staging instance of ServiceNow, you will need to update your extension URLs to reflect your production instance of ServiceNow, or the bidirectional integration will not work, because webhooks would in this case be sent to the development/staging instance of ServiceNow.
Make sure the escalation policy is assigned the incident in PagerDuty, whose corresponding incident in ServiceNow wasn’t updated (or for which no ServiceNow incident was created), has a corresponding assignment group in ServiceNow
Because the escalation policy is assigned the incident, ensure there is an assignment group that has its PagerDuty Escalation field set to the escalation policy’s ID.
You may need to add the two PagerDuty fields to the group form or list view to view their values.
Check to see if the webhook messages have been saved in ServiceNow. In ServiceNow, go to PagerDuty → Imports → Webhook Import Rows and look for records with creation time that coincides with the time that the incident in PagerDuty was triggered, acknowledged or resolved.
Check to see if you have any custom choices set up for the State field in the ServiceNow incidents model:
- Right click on the label of the State field (i.e. that would say "New" or "Resolved"),
- Select Configure Dictionary
- Switch to Advanced view
- Go to the Choices tab and look for entries with higher numbers in the Value field.
The integration follows the same convention as the out-of-box state values of ServiceNow. Higher numbers imply a more advanced state (i.e. a 6 or higher would be done/resolved or some variant thereof). If the state of the incident that did not automatically resolve is of a higher numeric value, but the incident did not resolve, it is because it was treated as already resolved.
To correct this, you will need to modify the custom choice values that you have configured for the State field to be lower than 6, so that they are treated as an unresolved state (if they reflect that).
Automation, while powerful, can interfere with and dramatically change the behavior of the synchronization if not designed carefully. Make sure that your automation in Inbound Field Rules and your custom import map code does not set fields in a way that interferes with webhook importing. You can view more information on this in our Advanced Configuration article.
Check the user's email address in ServiceNow to make sure it matches the user's email address in PagerDuty, and that the user is provisioned.
- Synchronization doesn't happen in real time but is handled whenever the incident record in ServiceNow is updated, or manually initiated by selecting Refresh PagerDuty Notes from the context menu in the ServiceNow incident header bar.
- The user posting the note might not be provisioned in PagerDuty, i.e. does not have a PagerDuty user ID assigned, and automatic provisioning (the option "Automatically create a PagerDuty user if one is not found matching the user's email") is disabled, and one of the following applies:
- There is no value set for the option "Default PagerDuty User ID to use if auto-provisioning is disabled" in Configuration → Properties.
- There is an incorrect/invalid value set for this option. The value must be a PagerDuty user ID, which is the uppercase alphanumeric code at the end of a given user's profile URL.
You can reenable the menu item to bring it back up and run the migration. To do this:
- Go to System Definition → Application Menus in ServiceNow.
- Search by Title for the PagerDuty menu and click its name to open and edit it when it comes up.
- Under the menu items, look for the "MIGRATE WEBHOOKS" one and check the box next to it.
- In the Actions on selected rows dropdown, select "Change active state".
- Refresh the page, go to the PagerDuty application in the system menu, and you should find the menu item.
While feedback loops can result from custom business rules and/or automation in ServiceNow, it is also possible in the integration to make the mistake of creating a webhook-powered 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 overview of an 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.
The feedback loop is as follows:
- Incident changes assignment group to (or is created in) B.
- PagerDuty incident triggered and assigned to Z.
- Webhook (escalation restarted;
- Webhook import in ServiceNow assigns incident to A.
- Automation changes assignment to B.
- Loop repeats.