How to use CSDM to Improve Incident Management

It’s been a while since this article was originally published, so I thought it would be time to update it to reflect changes to the CSDM model and our latest thinking. We published this article first in 2020 when ServiceNow’s Knowledge event included the first CSDM-related labs. People were getting excited about the data model and related use cases.

Today, the “value of CSDM” is a prevalent discussion topic in the ServiceNow Community. Many say there is no value in the CSDM as such but that the value comes from how the data is used. I fully agree, and one common and clear use case for CSDM data is Incident Management.

The data model has evolved a lot since the 2.0 version referenced in Knowledge 2020, and so have the ServiceNow Products utilizing the model. According to “Incident Management Product view” in ServiceNow Docs, the following are listed as “Incident Management features that get the most benefit from the CSDM”:

• Agent Workspace gives agents the information they need to quickly prioritize and resolve incidents.
• The major incident workbench includes a single-pane view you can use to identify, track, and resolve high-impact incidents.
• The native mobile app allows agents to quickly view and respond to tasks on-the-go, and can approve the requests with a single swipe.
• Incident deflection encourage self-help by suggesting related knowledge base articles.
• Improves collaboration on incident tasks by using drag-and-drop functionality on visual task boards.
• Performance analytics provide detailed insights into performance trends.

The core of all these features is still based on good quality data in the Configuration Item, Service Offering, and Service fields on the Incident form and the referenced tables behind those fields. Going through each of these features would require another article, so in this article, I will describe how:

• CSDM is referenced by the Incident Management
• an incident assignment example works
• DCM can help to ensure that required data models are followed

CSDM/CMDB Data on the Incident Form

1. Service– References the [cmdb_ci_service] table
2. Service Offering (attribute)– References the [service_offering] table
3. Configuration Item– References the [cmdb_ci] table
4. Affected CIs– Related list [task_ci] table
5. Impacted Services/CIs– Related list [task_cmdb_ci_service] table
6. Service Offering – Related list [task_service_offering] table

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

Checking just recently, I was happy to see that a brand-new developer instance using the Tokyo release now includes these fields on the form view by default. Only the “Service Offerings” related list was missing.

Good guidance on configuring your Incident Management to align with the CSDM can be found in a Community article with a matching title.

By default, these fields do not include much logic, but they can 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 Incident Management from the CSDM.

1. Services
2. Service Offerings
3. Configuration Items (CI)

The idea with CSDM is that each Configuration Item belongs to a Service. A 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 the Service Desk to report an issue related to a CI, that CI should be connected 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 a 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 assigning a ticket to a Support Group defined on a Service Offering.

“Ensure you have CIs properly related according to CSDM”

Scott Lemm, ServiceNow

To ensure that this auto-assignment works, you must “Ensure you have CIs properly related according to CSDM″ as described by the Knowledge lab instructions. But how do you 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.

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.

In this blueprint, we start from the Incident. And assume that Incidents should be always related to Configuration Items with a “Depends on” or “Contains” type of CI relationship to a Service Offering.

We could also draw this blueprint without the Incident and start from the CI class to ensure that all our CIs have references to Support groups either directly or via a Service Offering.

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

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

Here’s an example of a CI structure related to “ServiceNow PROD” Application Service where “ServiceNow DevOps” is one of its Technical Service Offerings.

If we take an Incident example where “ServiceNow PROD is down” and have a proper CI selected to see how Service Offerings are filtered based on CI selection and how an Assignment group is populated based on the Support Group on the Service Offering.

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

Then we select a Service Offering (4), which are nicely filtered based on the selected CI and its relationships to Service Offerings (5).

It 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! It can provide more clarity on overall responsibility and helps 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 take care of end-user communications and verify that the incident has been appropriately resolved.

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

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.

How to Ensure Your CIs are Properly Related According to CSDM

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

1. Check that you have all “CSDM fields” visible on your Incident form.
2. Configure Service, Service offering, and Configuration item fields to work in sync.
3. Ensure you have CI’s properly related according to CSDM.

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

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

Thanks for reading!

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