operational configuration items

[rbettencourt]

Hi folks, 

What operational configuration items can be selected and populated in the configuration item field on an incident or change request record?

[PoonkodiS]

Hi @rbettencourt 

Operational configuration items (CIs) in the Configuration Item field of an incident or change record represent any manageable component in the CMDB needed to deliver IT services. These include

physical infrastructure (servers, routers), software, cloud resources, logical components, and business or technical services

Example:

I created a Virtual Server CI and related it to an Application Service CI in the CMDB.

The relationship is defined as:

• Application Service → depends on → Virtual Server

With this relationship in place, if an issue occurs on the Virtual Server (for example, server down or resource issues), ServiceNow can identify which Application Services are impacted through impact analysis.

This setup helps ensure:

• Incidents are logged against the Application Service to reflect business impact

• Changes on the Virtual Server show the affected Application Services

• Proper impact and risk analysis using CMDB relationships

As long as the relationship direction is correct and the CIs are operational, affected services will be visible when server issues occur.

Hope this helps .

Thanks,

Poonkodi

[Alec Hanson]

In direct response to the question @rbettencourt , when you look in a new SN installation, then you can select anything that is:

- Not a Service Offering

- Not in 'Retired' Operational Status 

- Is a Principle CI (if there is at least 1 selected)

So this is in effect configurable by selecting the Principle CIs - but I am not sure what the best guidance is for 'Principle CIs'

So for example @PoonkodiS if you add on the VM Instance

• Application Service → depends on → Virtual Server ->  Instantiated by -> VM Instance

So would we expect the VM Instance to be a Principle CI? Would we raise Incidents on these CIs on just the Virtual Server itself?

Alec

[Jonathan Rousse]

Hi,  Application service and Dynamic CI group are operational Configuration Items that can be selected and populated in the configuration item field on an incident or change request record.

[Mathew Hillyard]

Hi @rbettencourt 

First of all, Incident and Change are separate processes, so the Configuration Item has a different purpose:

• Incident: the causal CI of the Incident
• Change: the CI that is the focus of the Change Request

You also need to be aware of some important facts about these forms:

• Whilst the Principal Class filter (a reference qualifier on the Configuration Item field that filters what you see to only CIs whose "Principal Class" flag has been selected in CI Class Manager) works relatively well, the Service And Service Offering fields are less well-governed, and as a whole the fields do not filter based on what you choose in the other fields.
• The base system is not configured to enforce good data governance.
• Despite CSDM having been released for many years, ServiceNow has provided little formal guidance - nothing that I have seen relating to Change Management, and only this article on Incident Management: https://www.servicenow.com/community/itsm-articles/how-to-configure-incident-management-to-align-wit... - and have a read of the comments to see some robust debate on the best approach.

So rather than rely on patchy platform guidance, work out what you want to present, and make it as easy as possible for the user (or for automation, as the vast majority of Incidents in most environments are created by systems rather than people).

• Filter the Service field to only show Business and Technology Management Services.
• If you pick aService, filter the Service Offering field to only show the Offerings for that Service
• If you pick a Service Offering field first instead, auto populate the Service field (the Parent field on Service Offering is mandatory and is a reference to its Service).
• If you pick a Service Offering field, filter what you can choose in the Configuration item field to only those CIs that provide that service. That is - Service Offering connected to Service Instance connected to its CIs (at any level of the hierarchy up to the maximum of 8 levels).
• If you pick a Configuration item first, the Principal Class filter should apply. Then filter the Service Offering field to either
  • Auto-populate if that CI resolves up to only one Service Offering, and then auto-populate the Offering's parent Service; or
  • Filter the Service Offering field to only show those Service Offerings linked to that CI
• The Configuration Item field will show both infra CIs and records that extend the Service Instance class. If you populate a Dynamic CI Group as the CI on a Change and save the record a Business Rule "unpacks" the CIs in that DCG into the Affected CIs related list. This was originally designed to streamline populating patching changes but watch out - if your DCG has 10,000 CIs and you then refresh impacted services, expect your session to hang and timeout. You have been warned 😉

You could go one step further and narrow down the options. I prefer to make the Service read-only, the Service Offering mandatory and then just follow the above. The guidance to helpdesk is to focus on the Service Offering as the main entry point. This works for Incident, Change and Problem. However, it's flexible enough to leave all three fields editable, to start from the Service first, the Service Offering first, or even the CI (which I'd not recommend on Incident as you often do not know the causal CI at creation).

In summary, consider the people and process as a whole, and make it as easy as possible to achieve good, accurate data quality.

I hope this helps!

Mat