How to use the Common Service Data Model in Incident Management

It’s Knowledge20 time! ServiceNow’s biggest customer event went online this year and we can all enjoy online keynote speakers, customer presentations, CreatorCon labs etc. and mostly at our own pace.

One thing that really caught my attention was the Lab session focusing on using CSDM in different stages. This lab included exercises and “gifts” related to Incident Management and how CSDM can help with auto-assignments and evaluating impacted business applications.

Earlier this year, ServiceNow also published separate use case documents about using CSDM together with ServiceNow products. One of these use cases was “Incident with CSDM 2.1” that is available via the NowLearning platform. Let’s have a look at that use case description together with these more recent lab exercises.

In this blog, I will describe how:

  • CSDM can be used in Incident Management
  • the incident assignment “Gift” from CSDM lab works
  • DCM can help to ensure that required data models are followed

CSDM/CMDB Data on the Incident Form

As described in the incident use case description, an incident ticket can relate to CSDM data with following references and relationships:

  1. Service form attribute references cmdb_ci_service table
  2. Service Offering form attribute references service_offering where said offering has a current parent Service
  3. Configuration Item form attribute references cmdb_ci
  4. Affected CIs form related list task_ci
  5. Impacted Services form related list task_cmdb_ci_service

The Service Offering reference is missing from an out-of-the-box form layout, but it’s available under the hood and can be added to the form layout easily.

Example with Demo Data

When using some demo data as an example, the incident form looks like this after adding the Service Offering field into default form view.

Incident Form - CSDM Fields

In the lower half of the form, we can see two related lists that also related to CMDB data.

Incident Form - CSDM Lists

By default, these fields do not include much logic, but these could be utilized much more efficiently when CMDB data is following the Common Service Data Model. To sum this up from the CSDM point of view, these are the elements utilized by the Incident Management from the CSDM.

Using CSDM on Incident Model
  1. Services
  2. Service Offerings
  3. Configuration Items (CI)

The idea with CSDM is that each Configuration Item belongs to a Service. Service can be either “business service” or a “technical service” depending on the CI and its place in the service taxonomy. For example:

  • if a customer (end user) calls to Service Desk to report an issue related to a CI, that CI should be related to a Business Service Offering subscribed by the customer.
  • If an IT expert reports an incident related to a database instance, that CI should be related to a Technical Service Offering responsible for maintaining and/or supporting the database.

Next, we will look at how these CI to Service relationships can be used in the Incident Management process.

Incident assignments using CSDM data

According to the CSDM, every Configuration Item should have a relationship to a Service Offering that’s part of a Service. This creates a simple hierarchy that can be used to auto-populate or filter other fields on the form when one of them already has a value.

For example, if a Configuration Item is filled in and it is related to a single Service Offering, we can automatically fill in the matching Service Offering and Service values. Or if CI is related to multiple Service Offerings, we can filter down the selection to only include related offerings.

These service details can then be used to automatically fill in other fields on the form, such as assign a ticket to a Support Group defined on a Service Offering.

“Ensure you have CIs properly related according to CSDM 2.0”

Scott Lemm, ServiceNow

The “gift” from ServiceNow gives an example on how to implement the auto-assignment based on selected Service Offering. In order to make sure that this auto-assignment actually works, you need to “Ensure you have CIs properly related according to CSDM 2.0″ as described by the lab instructions. But how to ensure such a thing?

First you need to understand the data model behind this functionality. The image above, showing the elements of the CSDM related to Incident Management can be extended a bit to include related Groups and responsible persons.

Example Data Model

The blueprint below will show an example of a data model that should be followed to ensure that auto-assignments work as planned.



Incident Assignment Data Model
DCM Blueprint for Incidents using CSDM data for auto-assignment

In this blueprint we start from the Incident. And assume that Incidents should be always related to Business Services when a customer or end user is the caller. We could also draw this blueprint without the Incident and start from the CI class.

With a proper filter on the CI, we could run an audit against all “operational CIs” to ensure that each CI has the required information in place to utilize the auto-assignment functionality.

Auto Assignment and Service Offering Filtering in Action.

Here’s an example of a CI structure related to “Electronic Messaging” Business Service where “Exchange Email” is one of its service offerings.

Running continuous audits against these blueprints will make sure that data will remain in good shape and people can focus on most important parts of the data model to enable the wonderful capabilities provided by discovery, especially when connected to the new Common Service Data Model.

Email Service Data Example
Example Business Service configuration – Dependency view

If we take the previous Incident example where “Email server is down” and this time select the proper CI to see how Service Offering is filtered based on CI selection, and how an Assignment group is populated based on the Support Group on the Service Offering.

Using CSDM on Incident

First, the CI is selected (1), but “EXCH-SD-05” doesn’t have a Support Group (2) defined, so the Assignment Group (3) on Incident remains empty.

Using CSDM on Incident 2

The Service Offering selection (4) is nicely filtered (5) to one offering based on the selected CI and its relationship to the Service Offering.

Using CSDM on Incident 3

And after selecting the Service Offering, the Assignment Group (6) and Service (7) are automatically populated with related information from the Service Offering.

Works like a charm! Once you have your CMDB populated according to the Common Service Data Model.

Using Incident Tasks with CSDM

Are you using Incident Tasks within Incident Management? Great! This can provide more clarity on overall responsibility and assigning child tickets to responsible persons and groups based on the underlying service configuration.

This is not really a part of the CSDM model or any recommendation from ServiceNow, but we have found it to work very well. Service Desk is usually responsible for all incidents and the Service Desk Agents usually take care of the end user communications and verifying that the incident has been resolved properly.

Many organizations are using Incident tasks to assign ticket handling to different teams while keeping the overall responsibility on the Service Desk. From CSDM point of view, this can be simplified in a way that Incidents are always connected to Business Service Offerings and Incident Tasks are always connected to Technical Service Offerings.

Incident Task Assignment Model
Incident assignment model when using child tasks

The only exception to this would be that “technical teams” are raising incidents for themselves. In such a case, the “Impacted Services” list could be populated based on all related Business Services while keeping the Service Offering reference to the Technical Service Offering.

How to limit the Service Offering selections then? With subscriptions. Customers and End Users are subscribed to Business Service Offerings while operational teams can subscribe to their own Technical Service Offerings.

I could write another blog about this with more details, if you?re interested.

(please comment below to let me know!)

Ensure you have CIs properly related according to CSDM (or any other model)

The lab exercise briefly described how to get the Incident Assignment based on Service & CI into use. And it all started with these simple steps.

  1. Install Update Set (provided as part of the lab exercise)
  2. Ensure you have Service Offering visible on your Incident Form
  3. Ensure you have CI’s properly related according to CSDM 2.0

Let’s stop there. Data Content Manager is the best tool available that can help you to ensure that you follow the CSDM or any other data model within your ServiceNow instance.

We have published a CSDM Content Pack into the ServiceNow Store that includes ready-made blueprint templates based on the Common Service Data Model whitepapers. Using these templates and the DCM Audit functionality will get you on the right track within minutes.

One example of using a blueprint template to audit your own data can be found from this video.

Thanks for reading!

To find out more about Data Content Manager, please get in touch with us or book a demo!


Mikko Juola

Chief Product Officer at Qualdatrix


Built on now
Built on now
Share This