What's New in ServiceNow V7.5 Integration

Today, I’m excited to announce the availability of the latest version of PagerDuty’s certified integration for ServiceNow. The latest version (version 7.5) is now available as a certified integration in the ServiceNow AppStore for New York, Orlando and Paris . It’s packed full of exciting new capabilities that enable you to drive real-time incident response and update the business stakeholders of the potential business impact right from within ServiceNow.

If you’re ready to get started, quickly read the upgrade tips at the bottom and then follow the installation guide once you’ve installed the integration from the ServiceNow Store.

What’s New in v7.5

Improved Bulk Provisioning

Building upon our v7.0 release, we have made additional updates to our bulk provisioning capabilities to streamline provisioning of business and technical services and their dependencies. We now provide additional customizations around selecting CIs to be provisioned. Whether you have a well-defined CMDB or not, you will be able to customize your service provisioning to meet your needs.

Use Service Classification Where Applicable

For implementations that have CIs from the CI classes that are set up with service classifications, you can now use that field to determine which CIs get provisioned as business or technical services in PagerDuty.

Select CI Classes to be provisioned as Business or Technical Services

If you are not using the service classification field or for other CI classes where this field is not applicable, you can now select which CI classes to be provisioned as technical or business services in PagerDuty. This configuration also allows for CIs to be provisioned as boththat are both business and technical services by selecting the CI class in both types slush buckets…The services and its dependencies from the target table would be only selected based on the CI classes selected for provisioning, all other CIs not matching the selection will not be provisioned.

Select the CI table containing CIs

The CI table is then the target table from where the list of CIs will be selected and their dependencies will be fetched based on the CI classes added in the slush buckets. The fetching process will run through all levels and retrieve the CIs matching the criteria to furnish the View Services table.

Select a Filtered List of CIs

Once the CI classes and the target table have been selected, we now allow the ability to filter CIs matching a set of filter conditions as welleven more. For example, a filter could be set to only use CIs that are setup for production use, thus enabling to retrieve only a filtered list of CIs from the table to be considered for provisioning.

View Services and Provision services

Once the CIs are retrieved and furnished in the View services table, we have now added the additional ability to review and fix any validation errors/missing information before provisioning bulk services.

The view services table allows to update, remove and verify the CIs and dependencies before bulk provisioning. The ability to fix any missing information and revalidate the CIs is also available.

We have also added the capability to provision the dependencies or additional services mapping to an existing mapped service on PagerDuty. To achieve this, select the existing table consisting of the mapped services and select the right CI classes to be considered for retrieving dependencies. The view services table will retrieve the existing mapped CIs as well and during the provisioning step, the provisioning service will identify it as a mapped service and only provision the dependencies to the existing service. This will allow all existing customers to utilize the bulk provisioning to the full extent by allowing them to map dependencies to existing services.

Provision a Single Cl With Dependencies

Furthermore, we have now also brought the single CI provisioning capability which allowed customers to provision a single CI along with its dependencies within the same configuration. The customers can now choose to do a bulk services provisioning or a single service provisioning or both, all using the same configuration within the same page. This allows a single CI to be provisioned and the dependencies matching the CI classes selected will be fetched to provision.

For even more detailed provisioning, we now provide the ability to select a single CI to be provisioned. This ability is best used for adding new dependencies to an already existing service in PagerDuty.

With all these new capabilities, provisioning services into PagerDuty is now more flexible than ever before. Whether you’re provisioning for the first time or making updates, we have you covered with our bulk provisioning features.

Custom Provisioning

In continuation to the existing capability of custom services and dependencies provisioning, we have now moved this capability under Provisioning using CMDB relationship dropdown with the value No(custom relationship).

Using this capability, the customers choose the parent and the child CI target CI tables, and set filter conditions to retrieve the CIs from the tables. The CIs will then have n x n combinations on the view services tables from both parent and child CI tables, the customers will need to update, remove and verify the custom relationship before provisioning.

Provisioning errors

We have also added the additional capability to display any errors found while services were provisioned after the provisioning. The customers can review this on the view services table under the provisioning errors column, rectify if possible and try again to provision. This allows identifying any provisioning or validation errors, and rectifying is easier than before.

Ability to Send Change Request Information from ServiceNow to PagerDuty as Change Events

When an incident occurs, responders need as much information as possible to resolve the incident. Now, responders will be able to see change request information from ServiceNow appear in PagerDuty’s change events dashboards. This information provides valuable details into recent changes directly within PagerDuty. In addition to syncing change request information, maintenance requests can be automatically set in PagerDuty from the change request in ServiceNow. A maintenance window will ensure responders do not receive unnecessary alerts during the implementation of a change.

To enable this, please follow the steps on the userguide to allow integration of change requests from ServiceNow to PagerDuty on a CI.

Tips for Upgrading

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

  • Consider testing the upgrade path in your development environments first.
  • If you have made customizations to the PagerDuty Integration, you must first backup, then revert your customizations. You can then upgrade and re-apply the customizations if necessary.
  • Why? The ServiceNow App Store won’t patch files that have been modified/customized by customers. If you have customizations.

How can I find out if the integration has been modified?

The easiest way is to check the Updated By attribute for each of the files in the PagerDuty integration.

  • 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, it’s a good sign that someone in your organization modified the file.
  • Compare the changes to the original version, document your customizations and revert to the store version.
  • After you upgrade, you can determine if these customizations are required again and re-apply.

Upgrading PagerDuty Extensions (Webhooks)

As part of the Integration update, there’s a new type of Extension (or Webhook) in PagerDuty. The integration ships with a script to update the PagerDuty Extensions with a single click.

  • After upgrading, verify that the PagerDuty Settings page is up to date.
  • In particular, ensure that “ServiceNow user for authentication” and “ServiceNow user password for authentication” are present, as these are needed by PagerDuty to communicate with ServiceNow.
  • Run both the Test REST API Connection and the Test ServiceNow User Authentication scripts. Both should return a “success (200)”.
  • Run the MIGRATE WEBHOOKS to v7.5 script. Output will be displayed and upon completion, a success message will display. This script removes your existing v5.0 or v6.0 Extensions from your PagerDuty account and adds new v7.5 Extensions.

Questions? Feedback?

If you have any questions or feedback on the integration, let us know.