What's New: PagerDuty v4 Integration for ServiceNow


(Sean Higgins) #1

Today, we’re excited to announce that version 4 of PagerDuty’s certified ServiceNow integration is now available! Many of the new features and functionality included were driven by pain points highlighted by our customers and has been well received by those using version 4 as part of an early access program. This update makes the bi-directional integration between PagerDuty and ServiceNow even more seamless and easier to customize.

Version 4 is certified for both Helsinki (all patches), Istanbul (all patches), Jakarta (Patch 6+) and Kingston (all patches).

What’s New

Integration with your Configuration Management Database (CMDB)

  • You can now map Configuration Items (CIs) from ServiceNow to PagerDuty – items such as Business or Technical Services or Applications.
  • This gives your responders additional context about the incident and enables you to more easily report on the most problematic services or applications in your infrastructure.
  • Automatically populate CI information on ServiceNow tickets, from PagerDuty – with our Inbound Field Rues feature, you can extract key information from monitoring tool events routed through PagerDuty, perform a lookup against your CMDB and populate necessary information into your tickets.

Populate any field on your ServiceNow tickets with dynamic or default values

  • If you have mandatory fields required on creation or resolve, you can now easily populate this information using the Inbound Field Rules feature.
  • Data can be extracted from PagerDuty (and your monitoring tool events) and be populated into the necessary fields. You can also perform lookups against other tables in ServiceNow to retrieve additional information.

An example of when this might be useful:

  • Your monitoring tools identify an issue and send an event to PagerDuty. Your on-call engineers are paged and a corresponding ticket is opened in ServiceNow via the integration.
  • You can now set fields such as the Caller, Category/Sub-Category fields and the Configuration Item field – all automatically.
  • Alternatively, when an incident is resolved, you can populate the Close Code and Closed By values.

Take a look at the Advanced Configuration article in our knowledge base for more info.

Incident Priority Synchronization

Recently we introduced Incident Priority, allowing you to classify your PagerDuty incidents and you can now keep the priority values for your ServiceNow tickets and PagerDuty incidents in sync. If an incident is upgraded or downgraded, the value will be updated in both systems.

Note: you can also customize the priority levels and labels in your PagerDuty account so that they match what you use in ServiceNow. Checkout the support article for how to get started.

Out-of-Box support for custom modifications

In earlier versions your advanced workflows in ServiceNow required that you make some modifications to how the PagerDuty integration works. However, when you modify the integration, this impacts your ability to easily upgrade via the ServiceNow App Store.

In version 4, you’ll notice a new Script Include called PagerDutyInboundCustomScript. This is now the recommended place to write any custom code as part of the transform when webhooks are coming in from PagerDuty – customizations such as state changes to your tickets when incidents are acknowledged or resolved in PagerDuty.

Easier provisioning of users into PagerDuty

One of the frustrations when setting up the PagerDuty integration is provisioning only users in certain Assignment Groups. ServiceNow doesn’t make it easy to filter by group memberships from the Users list.

You can now provision users from the Group Members tab, when viewing an Assignment Group in ServiceNow. Simply select the users you want to provision into PagerDuty from the Group Members tab, then choose Provision PagerDuty Users from the action drop down.

Security Improvements

The PagerDuty integration now operates under a service account in ServiceNow, giving you more control over the permissions that the integration has. All you need to do is create a new service account and provide the credentials in the integration. When PagerDuty sends data to ServiceNow, the requests will authenticate using the user account configured.

For added security, all traffic from PagerDuty will come from a specific set of IP addresses found here. If you use IP Address whitelisting, be sure to add these IP addresses to your whitelist.

If you’re an existing user of our PagerDuty integration, check out the tips below for upgrading then review the install guide. If this is a fresh install, head on over to the ServiceNow App Store to get started and follow the install guide.

Tips for Upgrading

Before you start the upgrade process for the PagerDuty integration, here are a few things to consider:

Backup and revert any customizations you have made to the PagerDuty Integration
Upgrades via the ServiceNow App Store won’t patch files that have been modified in your ServiceNow instance. This means that the PagerDuty integration can end up in a broken state.

  • In ServiceNow, navigate to PagerDuty → Configuration → Configuration Files
  • Update the Form Layout to show the Updated by and Updated columns to the view for all of the tabs (Business Rules, Script Actions, Includes, UI Actions, etc.)
  • If the Updated by value is not PagerDuty, you will want to save these customizations.
  • Review the Version History and restore to the earliest version.

Create a ServiceNow service account before you upgrade

  • Create an account for the PagerDuty integration to use, before you upgrade. This way, you minimize the amount of time that the integration may not be functioning.
  • Grant the account access to the rest_service and itil roles to ensure it has access to the ServiceNow REST APIs and can move your incidents through the incident lifecycle.

Don’t run the MIGRATE WEBHOOKS script until after you configure the service account

  • When you run the MIGRATE WEBHOOKS script, the Extensions in your PagerDuty account are updated to include the authentication information (encrypted) for ServiceNow.
  • If you don’t provide the service account information in PagerDuty → Configuration → Properties first, the Extensions on the PagerDuty side won’t contain the service account info.
  • You can check out this Troubleshooting article if you miss this step.

Other Helpful Resources
Here are a few helpful links that will help you with your installation or upgrade process:

If you have any questions, comments or need assistance upgrading, please let us know.

Getting custom details through v2 webhooks
(Sean Higgins) #2

Today we released an update to version 4 (v4.0.10) of the PagerDuty integration for ServiceNow. This update brings bug fixes and is also certified for Jakarta Patch 6. The update can be installed via the ServiceNow Store.

Organizations will need to be running Patch 6 of Jakarta (or higher, once available) in order to install the PagerDuty integration. This is due to a critical fix that within ServiceNow that was released as part of Patch 6 (documented in the release notes under problem PRB1235252).

Bug Fixes in this update

  • Protection Policy was incorrectly set as “Read Only" on the PagerDutyInboundCustom Script Include.
    • If you are currently running version 4 on Helsinki or Istanbul, this update introduces a new Script Include called PagerDutyInboundCustomScript that should now be used for any custom scripting.
    • Customers on Helsinki, Istanbul and Jakarta should all use the PagerDutyInboundCustomScript for customizations
    • The previous script include, titled PagerDutyInboundCustom, now has the active flag set to false
  • Re-assignment Fixes
    • If both the Assignment Group and Assigned To fields were changed at the same time, the Assignment Group field previously could be incorrect. This will no longer occur.
    • If you specifically set the Assigned To field, it would immediately clear the value if the integration was configured to only assign on incident acknowledgement
  • Inbound Field Rules: it was possible to configure rules to overwrite values that were already set in the ServiceNow Incident. With this update, if a ServiceNow incident already has an incident attribute populated, Inbound Field Rules will not overwrite the values.
  • It was possible to create an Incident in ServiceNow with an incorrect sys_id if PagerDuty integrations were explicitly setting the incident key to a value that contained non-hexadecimal characters

Upgrading from an existing version of v4.0

  • This upgrade, from existing v4 installations contains no breaking changes. Properties that are already configured will remain untouched.
  • Existing files that have been updated in this release include:
    • Script Include: PagerDuty
    • Web Service Transform Map: PagerDuty Webhook Import

Upgrading from a pre-v4.0 installation

  • See my initial post about “Tips for upgrading"

If you have any feedback or comments on the version 4 release, please let me know. Thank to you everyone who has provided feedback following the initial v4 release in September.


(Sean Higgins) #3

This week, we rolled out a small update (v4.0.13) of the PagerDuty integration. This version brings Certification support for ServiceNow Kingston! This version is also certified on Helsinki, Istanbul, and Jakarta Patch 6+.

What’s Included in v4.0.13:

  • Fix related to work notes on Jakarta and Kingston

Tips for Upgrading:

  • If you’re already running v4.0.x of the integration, this upgrade contains no breaking changes. Properties that are already configured will remain untouched. If you haven’t modified any code, simply upgrade via the ServiceNow Store.
  • If you have customizations made, you must revert these before you upgrade. The following existing files that have been updated in this release
    • Script Include: PagerDuty
  • If you are running ServiceNow Helsinki or Istanbul and will soon be upgrading to ServiceNow Jakarta or Kingston, you should upgrade to v4.0.13 before you upgrade to Jakarta/Kingston
  • If you are on v3.x of the PagerDuty integration, please take a look at the “Tips for Upgrading” section of my initial post

A small FYI on required fields during state changes in Kingston:

  • If there are mandatory fields for State changes that are left empty in ServiceNow, you may not see any warnings in the UI when attempting to change the incident State. These errors only appear to be showing in the system log.
  • If you are Resolving an incident in PagerDuty but don’t see the incident being Resolved in ServiceNow, check for your required Incident required fields. These are likely not being populated.
  • You can build Inbound Field Rules to populate your mandatory fields. Check out the support article here.
  • Most common use case is required fields when an Incident is Resolved. You can easily build two Inbound Field Rules to populate the close_code and close_notes when an incident.resolve webhook comes from PagerDuty.

As always, if you have any feedback or comments on the version 4 release, please let me know.

(system) #4