The Services Provisioning feature allows users to provision Configuration Items from ServiceNow as business and technical services in PagerDuty. Users may optionally configure preferences for bulk provisioning on this screen as well. Access this feature in ServiceNow under PagerDuty Services Provisioning.
Required User Permissions
x_pd_integration.adminrole is required in ServiceNow to provision services and users in PagerDuty.
Before provisioning Configuration Items as services in PagerDuty, we recommend the following:
- Read our Full Service Ownership Guide for best practices in planning your PagerDuty technical and business service relationships.
- Given the dependency relationships between business and technical services, review how you would like to map Configuration Item relationships, noting the higher-level CMDB classes and lower-level CMDB classes.
- Set the corresponding Assignment Group for each of the Configuration Items you will be provisioning. This simplifies the provisioning process; when you provision a single Configuration Item, it will verify that the Assignment Group exists in PagerDuty (as an escalation policy). If not, it will also provision the corresponding Assignment Group as a PagerDuty escalation policy.
With the PagerDuty integration, each ServiceNow Configuration Item can be associated with a corresponding PagerDuty service. This integration offers an easy way to quickly generate a new PagerDuty service and webhook, which is necessary to send information back to ServiceNow. It will also populate the associated fields in ServiceNow.
Any Configuration Item that extends the base
cmdb_ci table can be mapped to PagerDuty because it inherits the same field that contains the PagerDuty service ID. This makes it easy to map any type of Configuration Item to services in PagerDuty, although we recommend only provisioning business services, technical services and/or applications. For each Configuration Item type, the form view for it will need to be modified to show the PagerDuty object ID.
Under Provision using CMDB relationship table, you have two options for defining CI dependencies prior to provisioning:
- Yes (Default): Provision CIs and dependencies based on the CMDB relationships table (Option 1).
- No (Custom Relationships): Provision CIs and dependencies based on custom relationships (Option 2).
If you have a well-established CMDB, we recommend that you provision using the CMDB relationship table.
When provisioning based on the CMDB relationship table, you have two further options:
If you have defined the type of service classification on the CI class service items and would like to use that value to classify the service as a business or technical service, select the Use service classification where applicable checkbox.
- If you select the checkbox, and you have defined the service classification values, we will honor the value. Only the CIs with business and technical service classification type will be provisioned, but the application service type will be ignored.
- If the value is left empty, we will provision it based on the classification in the slush buckets below, else if the service class is selected under both service types then the CI will be provisioned as both a business and technical service.
- CIs that are both business and technical services will have an additional relationship provisioned in PagerDuty with the business service having a dependency on the technical service of the same CI.
If you have not defined the type of service classification on the CI class service items, or for other CI classes that you would like to provision into PagerDuty, select the CI classes which belong to business service type under the Business Services class slush bucket and select the CI classes which belong to Technical Services type under the technical service class slush bucket.
- Select the CI classes under Business Services for CIs that you’d like to provision as a business service.
- Select the CI classes under Technical Services for CIs that you’d like be provision as a technical service.
- Select the CI classes which could be both business and technical service under both the slush buckets.
- Avoid the CI classes which you do not want to provision into PagerDuty on both of the slush buckets.
- The CIs and dependencies will be considered based on the CI classes selected under both the slush buckets.
- All other CIs which do not match the classification will be ignored.
Once the CI classes are classified, under Choose Table with CIs or a single CI to be provisioned along with dependencies, select the CI table from where the CIs should be fetched. The dependencies will be identified for the items in the table based on the classes and they will be defined in the Services Provisioning Table.
Example : Selecting
cmdb_ci_service will provision the CIs from the service table along with its dependencies, which may or may not be restricted to the table.
If you would like to only select a filtered list of CIs from the selected table, then select the option Open selected table to set and save filter to save and select the filter in the next field. Note: The filter option will appear only after you set the table value. Also, you will need to manually select the saved filter name to apply the filter for your provisioning.
Next, select the column which will define the service name in PagerDuty. The Name value is set by default, though you may change it to another value if required.
You can provision a single CI along with its dependencies based on the configuration within the same user interface. Select the Provisioning single CI along with its dependencies checkbox, and then select the CI that you would like to provision with its dependencies, matching the CI classification set above.
Users can do bulk and single CI provisioning at the same time through the same configuration.
Save the different combinations of configurations if you would like to set different types of relationships, allowing you to set all the services and dependencies before provisioning.
Please read this user guide carefully before provisioning in bulk, as bulk deprovisioning is not supported.
The custom relationships provisioning configuration allows users to define the relationships between CIs without taking into consideration the relationship that exists within ServiceNow CMDB.
|Provision using CMDB relationship table||No (Custom Relationships)|
|Select CI Table containing services||Select the table which contains the configuration items you would like to provision.|
|Select Filter||Open the selected table and save a filter, or save a filter on the table view before selecting this value.|
The filter selected will be applied to fetch a filtered list of items from the table selected in the previous field.
|Select the type of service to be provisioned||Business Service or Technical Service.|
This selected value will apply to all the items on the selected table.
|Select column for service name||This value will be used for the name to set on the service on PagerDuty.|
Default value : Name
|Select the relationship between services to be provisioned||- Consumes: First being parent and second being child CI.|
- Consumed by: First being child and second being parent CI.
The first selected table and the second selected table items will have the above relationship between the services.
Once you’ve set the values, click Save Configuration.
The custom relationship is set between each item on both the tables, or if only one table is selected in both the values, then relationships are set between each item and the other items within the same table.
Example: A table is selected and filtered to provision the following list of configuration items:
- CI 1
- CI 2
- CI 3
- CI 4
- CI 5
- CI 6
Then the following relationships will be defined on the view services table:
Parent CI 1:
- Child CIs:
- CI 4
- CI 5
- CI 6
Parent CI 2:
- Child CIs:
- CI 4
- CI 5
- CI 6
Parent CI 3:
- Child CIs:
- CI 4
- CI 5
- CI 6
Please review this information and delete the relationships and services which do not meet the requirements, to ensure only the expected services and relationships are provisioned in PagerDuty. In other words, the custom relationship merely creates all possible relationships between the selected list of items, and you will need to remove any which are not required.
Once saved, the configuration will populate the potential services and dependencies in the Services Provisioning table (PagerDuty Services Provisioning Table), along with the service type.
Review the table information before provisioning the services.
The Validation warnings column will load any missing information on the services, which allows users to fix these errors before provisioning. Once the errors are fixed, click Revalidate services.
Change the service type if there are any service types not as expected on the view services table, also remove any services and dependencies which you do not want to provision into PagerDuty.
Once you have reviewed the list of services, click Provision Services. If there are any errors while provisioning, they will be captured in the Provisioning errors column. Fix the errors and retry provisioning.
Note: If there are older services, which were not provisioned due to errors or any other reason, delete these services/relationships from the View Services table before provisioning new services again.
This integration also allows you to provision users from ServiceNow to PagerDuty. In your ServiceNow Users list, you can see directly which users have already been created in PagerDuty as their PagerDuty ID field will be populated.
Select a user that has not already been provisioned to PagerDuty and select Provision PagerDuty User to add them to your PagerDuty account:
You will then see a notice that the user is being provisioned. Upon completion, the PagerDuty ID field is automatically populated. The user also shows up in PagerDuty, with the same name and email address.
You can also provision multiple users at once by selecting them and selecting Provision PagerDuty User from the dropdown on the Users screen.
Updated about 1 month ago