Should You Use a Dynamic CI Group as Configuration Item for Incident Management?

nmaneely
Mega Sage

If we have a Dynamic CI Group [cmdb_ci_query_based_service] for our Virtual Server estate (~1000 servers) which is 'contained by' a 'Virtual Hosting' Technical Service Offering, when logging an Incident with 'Virtual Hosting' as the Service Offering and a Reference Qualifier on the Configuration Item [cmdb_ci] field to show only CIs related to the Service Offering means that only the Dynamic CI Group record is available for selection in the Configuration Item field. If the Dynamic CI Group is selected and the Incident saved, unpacking of the Dynamic CI Group starts and populates the list of Affected CIs with all the ~1000 servers while adding a Work note for each server added to the Affected CI list.

Is this the expected way of working or should the Reference Qualifier on the Configuration Item be removed to allow the selection of a single CI? If I populate the Configuration Item field firstly with a single Virtual Server, I can select the Virtual Hosting' Technical Service Offering.

1 ACCEPTED SOLUTION

Barry Kant
ServiceNow Employee
ServiceNow Employee

hi nmaneely, 

I wouldn't use a DCIG in incident in cmdb_ci field. 
For Changes it is used sometimes eg if you define a DCIG as patching group and you need to patch x servers. That is the use case of this unpacking. 
For Incident I doubt it there is a thought about multiple affected CIs (as that is where it is unpacked) as rootcause CIs. Meaning ootb the impact analysis is only considering the cmdb_ci attribute as input for impact analysis. For me this wouldn't make sense. I would maybe change the reference qualifier to check the related DCIG and then look in the svc_ci_assoc table to all related CIs to the DCIG. Then you can select from the related CIs in the cmdb_ci attribute. I think that is a more realistic scenario. 
That said: that reference qualifier works only on the TSO side. For BSOs you still need to check downstream relations. So the reference qualifier might be a little complicated:
If Service Offering. service_classification = Technical Service then ..... else 
If Service Offering. service_classification = Business Service then .....


BR,
Barry

View solution in original post

3 REPLIES 3

Barry Kant
ServiceNow Employee
ServiceNow Employee

hi nmaneely, 

I wouldn't use a DCIG in incident in cmdb_ci field. 
For Changes it is used sometimes eg if you define a DCIG as patching group and you need to patch x servers. That is the use case of this unpacking. 
For Incident I doubt it there is a thought about multiple affected CIs (as that is where it is unpacked) as rootcause CIs. Meaning ootb the impact analysis is only considering the cmdb_ci attribute as input for impact analysis. For me this wouldn't make sense. I would maybe change the reference qualifier to check the related DCIG and then look in the svc_ci_assoc table to all related CIs to the DCIG. Then you can select from the related CIs in the cmdb_ci attribute. I think that is a more realistic scenario. 
That said: that reference qualifier works only on the TSO side. For BSOs you still need to check downstream relations. So the reference qualifier might be a little complicated:
If Service Offering. service_classification = Technical Service then ..... else 
If Service Offering. service_classification = Business Service then .....


BR,
Barry

Mathew Hillyard
Mega Sage

I'd echo @Barry Kant's comments. I'd go one step further and remove Incident and Problem from the Business Rule "Sync Affected CI Dynamic Group" filter condition and be very clear with your organisation when to set the Dynamic CI Group as the CI on a Change Request, as setting a DCG with a large number of contained CIs can cause issues, both when unpacking the CIs into the Affected CIs related list, and when refreshing impacted services. I would recommend sticking to individual causal CIs on Incidents and Problems.

nmaneely
Mega Sage

@Mathew Hillyard @Barry Kant - Thank you both for taking the time to post your replies both of which are most helpful.