Use of Application Service table and knowing real meaning behind how this works with ITSM Change Ma

[Community Alums]

On Change Management form, when we select a CI with existing Application services, impacted services related list will refresh, when changing the CI in the CI field list will refresh. However, when adding additional Impacted CIs using related list on change form, the impacted services related list does not refresh. When read community on same, it says the refresh would happen only if the Application Service was listed as or exists in Calculated Application Service. Need to understand why it is a must for service to be in Calculated Application Service for list to refresh when updating to manually add impacted CIs. However adding an Application Service as CI on change form is working as expected as well. So if related list needs to refresh, should all the Application Services be converted to Calculated Application services? Why and why not? What's the purpose of each table as per CSDM and why they are designed in such a way when working with a Change Management record? 

#ChangeManagement #ITSM #CSDM #ApplicationServices #CalculatedApplicationService

[Mathew Hillyard]

Hi @Community Alums,

I will assume that the Change properties for populating impacted services have been activated, and that you have application services related to CIs with CI Relationships and are aligned with CSDM.

It is not correct that Application Services must be of the calculated class to be pulled into Impacted Services. All Application Services and Dynamic CI Groups that contain within their service map one or more CIs in the Affected CIs related list of a Change Request will be populated in Impacted Services. There is one exception. You should not create records in the parent Automated Business Service [cmdb_ci_service_auto] table as this the parent table in the hierarchy that shows all child Calculated, Mapped and Tag Based Application Services and Dynamic CI Groups, but relating CIs to an Automated Business Service will not populate the Service Configuration Item Association [svc_ci_assoc] table (see below).

This data is stored in the Service Configuration Item Association [svc_ci_assoc] table. When you refresh impacted services on a Change request, what happens is that the list of Affected CIs is used to query this table, and it returns a unique list of related Application Services. This table basically "flattens" CMDB relationships.

However there can be reasons why the App Service and CI record does not appear in the Service Configuration Item Association [svc_ci_assoc] table:

1. For a Calculated or Mapped Application Service you choose the number of Levels (layers in the CMDB Hierarchy). If you choose 3, for example, and your CI is 4 or more layers down, a record will not be created.
2. The Manual CI Exclusions / Inclusions [svc_manual_ci_exclusions_inclusions] table contains a list of CI Classes OOTB and where the record is set to "exclude", where relating a CI of this class to an App Service will not create a record in the Service Configuration Item Association [svc_ci_assoc] table. It is possible (and recommended) to add all CI classes that you do not need to use in incident/problem/change to this table to keep the "noise" from Discovery from resulting in too many Service Configuration Item Association [svc_ci_assoc] records and to speed up the refresh of impacted services.

Here is a useful link to what each App Service Class does: https://www.servicenow.com/community/common-service-data-model/application-services-how-to-use-them/ta-p/2308712

I hope this helps!