Impacted Service related list - only Services or also CIs?

[Niclas]

Out of box it seems that when clicking Incident UI Action "Refresh Impacted Services", it only puts Services (based on CI Relationships and Incident CI) to the related list Impacted Services/CIs. However manually users can also add any other CIs out of box.

It's confusing, the naming seems to indicate it is especially designed for tracking impacted services, but still everything else can be added. Is CSDM recommendation to restrict this list to Services, or should we keep it allowed to add CIs there as well? 

[Barry Kant]

Hi Niclas, 

the logic/function limits it to services, and classes extended from services class.

That is also what the value of the tables is intended to contain so the potential impact to business and providing parties is known.

• This can be used for suggested approval audience.
• Target audience for notification/communication.
• Understand the supporting parties/routing.
• Creating outages.

In my opinion no manual entries should be made, but that is pretty much from a CMDB maturity point of view.

Note:
as of Paris version properties are used to lookup:

• cmdb relations
• cmdb associations (dynamic CI groups)

This have different results.

Best regards,

Barry

[Niclas]

Sounds valid and I agree. What you are describing is also my assumption. Just wondering why oob table label is "Impacted Services/CIs" with oob field Configuration Item referring to [cmdb_ci], instead of making it truely Service related. 

 

"the logic/function limits it to services, and classes extended from services class."
--> Would that include Service Offerings as well? Technically they are an extension of service class, but starting with Paris there is a new related list [task_service_offering] for them

"In my opinion no manual entries should be made, but that is pretty much from a CMDB maturity point of view."

Will Service Impact analysis via "Refresh Impacted Services" only consider the main CI stored in the Configuration Item field or does it also run through all "Affected CIs" [task_ci]? Last time I tested it seems to only go through the main CI. 

[Mary Vanatta]

This is all part of moving to a "Service-centric" view instead of a "CI-centric" view. 

The sole reason a CI exists is to provide an "Application Service" which is "used by" a  Service Offering which "refers" to a larger service. 

This is where the "Dynamic CI Group" comes in nicely.  This will contain all the "CIs" that are needed for say patch management on a bunch of servers. 

[Ben Rowny]

The Impacted Services/CIs list can contain any kind of CI you want, whether it is a Service or a phsyical/logical CI. However, the Refresh Impacted Services UI action, as its name implies, only searches for items in the cmdb_ci_service table (Services and their child classes such as Application Service, Service Offering).

If you want to mark other CIs as impacted, add them manually. Also, any CIs that you add manually, whether they be a Service or anything else, will stay on the Impacted Services/CIs list even if Refresh Impacted Services would not find them (e.g. you modified the primary CI for the change, or deleted a relationship between services).

As others have mentioned - it's done this way to encourage a Service-centered view of Change Management - and because the list of impacted CIs could otherwise get HUGE if it was using a similar calculation. Ultimately it's up to your organization to decide how best to use it. I would generally keep non-Service CIs in the Affected CIs list (and only if they will actually be directly touched by technicians doing the change), but definitely see some use cases for placing certain non-Service CIs in the Impacted list.