'Impacted Services/CIs' related list is showing different results in Incident vs change form :O

[Suggy]

I have a windows server - Win_test

It is associated with the Application services - A,B,C

For both Incident and change, the property 'Populate Impacted Services based on Affected CIs' is set to True.

1. On Incident form, when I chose the CI as 'Win_test' and clicked on 'Refresh Impacted services', then the 'Impacted Services/CIs' is populated with - A,B,C

2. On Change form, when I chose the CI as 'Win_test' and clicked on 'Refresh Impacted services', then the 'Impacted Services/CIs' is populated with - A,B,C, X

where X is a Configuration item (DB instance) running on that Windows server.

Questions:

1. Why X is not populated in incident management?

2. What is actually expected to populate in 'Impacted Services/CIs' related list? Only impacted Services or both 'Impacted services and CIs' as the name says?

[CMDB Whisperer]

In my opinion changing the the results based on whether Discovery or Service Mapping is implemented is the wrong approach.  We should have consistent results regardless, even if the algorithm to get those results differs.  And philosophically I just don't think it is as accurate to ascribe the term "impact" to CIs.  Impact is more appropriately ascribed to outcomes and outcomes are delivered by services.  The application is just another component of the infrastructure on the path to that outcome which is impacted.  After all, this is what makes IT service management possible, understanding what valuable outcomes are impacted by changes  and incidents in infrastructure.  If we get people thinking in terms of "is this application or hardware impacted by a change/incident" I think we actually do a disservice to the value that the platform and CSDM can provide.  At the very least there should be a system property that can turn off the addition of application CIs as impacted CIs.

[Barry Kant]

Hi all,

Comment from my side:
as this is a discussion for many years I started to use the (impacted) Service Offerings more often as on those records I tie the consumers (subscribers) so I use that for communication and outages. 
The related list is visible if the field on the form is not empty (weird logic..., I would prefer to show it if the property to include Impacted Service Offerings is set to TRUE). And the script include "TaskServiceOfferingSNC" function "GetOfferings" is not the way I expect it as it collects all Offerings from the parent filled in the form where I would expect it looks up all related offerings from the affected Application Services, similar is it does for Impacted Business Applications which is correct. (see post )
This way I can show total number of subscribers, and the criticality from the offerings. As an agent I can create outages where needed. Which can be shown in the welcome message in Virtual Agent if a consumer opens the Virtual Agent. (I made a tweak here as well to only list the subscribed services having an outages to put it in the context of the user. This all depends on using subscriptions of course. 
All in all I see this as value to users (agents as well as consumers via portal).

This has nothing really to do with the prime quest of this thread. 
The outcome of Impacted Services function based on similar CI(s) should be based on the model and not differentiate on the process (so the outcome should be equal). In impacted services no CIs are expected.
I know this is under review, but that is basically all I know.

BR,
Barry

[Mathew Hillyard]

Hi @Suggy 

Impacted Services/CIs table is populated from the Service Configuration Item Association [svc_ci_assoc] table. This table has two reference fields - one to cmdb_ci (CI Id) and one to cmdb_ci_service (Service Id), but practically speaking you should only ever see records that extend from the Automated Business Service [cmdb_ci_service_auto] table in the Service Id field because its population is defined when you build out calculated, mapped or tag based application services or dynamic CI groups with a valid CMDB group.

The only reason you will see Business and/or Technical Services in the Impacted Services/CIs related list is because a Business Rule on Incident/Change copies the Service from the form to this related list, and typically we would populate this field with the Business/Technical Service that is the parent of the Service Offering on the form.

The code that populates Impacted Services starts with the script include function TaskUtilsSNC().triggerRefreshImpactedServices(). From here it branches out separately for Incident and Change.

• Change uses ChangeUtilsSNC().refreshImpactedServices()
• Incident goes either via Events (and a Script action) or directly to TaskUtilsSNC().refreshImpactedServices()

Both routes ultimately end up at CIUtils()._getImpactedServicesFromAffectedCIs(). This is the short 14-line function that queries the Service Configuration Item Association table with the CIs in the Task's Affected CIs and returns a unique list of (Application) Services.

I've delved right into the weeds with this with a large CMDB during a big CSDM project and it works perfectly. The only possible reason you are seeing non-Application/Business/Technical Services in the Impacted Services related list is if either the above code (for Change) has been customized somewhere, or some other logic is copying data into the Impacted Services table on Change Requests.

Hope this helps!

[Suggy]

Hey @Mathew Hillyard Thanks for replying. You could see my previous update where I have tested in a NEW PDI. So obviously no customizations. I just used demo data, and as you see the 'impacted services/ci' is populated with 'Configuration items' as well.