Enabling the Change property:'change.refresh_impacted.include_affected_cis' in Madrid instance and the expected results are not showing up when a refresh impacted services option is used on Change Requests based on the attached Configuration Items of the Change Request.

London, Madrid

Records will be added to Service Configuration Item Associations table through Service Mapping. If Service Mapping is not used, then there won't be any impacted services displayed.

Steps to Reproduce:
In <instance>, create a Change Request.
Under the related lists, click on Affected CI's --> Add CI's
On the List Context menu, we do have option to click: Refresh Impacted Services
All the Impacted Services available in "svc_ci_assoc" table should be pulled.

Expectation: All the CI's should be added to the change request which are present in the table: Service Configuration Item Associations.

Misconception of how the Refresh Impacted Services UI Action works: All the records which are in the Relationship table of the CI will be added to the Change Request.

Original Behavior:

The functionality which is available in the current platform is working as per the data which is available in the table: "svc_ci_assoc"

Scenario of how the whole process works:

Once we click on Refresh Impacted Services, It will be checking the records in the table: "svc_ci_assoc" and retrieve all the unique records and attach them to the Change Record.

Now coming to the table: "svc_ci_assoc", entries into this table will be coming from the Service Mapping which will be done on the CMDB_CI records.

This table will hold all the relations for a CI created using Service Mapping.

If Service Mapping has not yet been implemented, this is what can be done to achieve the functionality with the current process:

Once Refresh Impacted Services is clicked, the whole process will eventually end up with the function in this Script Include: ChangeUtilsSNC
[code]

getImpactedServicesFromAffectedCIs: function(chgId, userId) {	
		var ciu = new CIUtils();
		var services = [];

		var taskCiGr = new GlideAggregate("svc_ci_assoc");
==>		taskCiGr.addQuery("JOINsvc_ci_assoc.ci_id=task_ci.ci_item!task=" + chgId);
==>		taskCiGr.groupBy("service_id");
		taskCiGr.query();

		while (taskCiGr.next())
			services.push(taskCiGr.service_id + "");

		if (String(gs.getProperty(ChangeCheckConflicts.CHANGE_CONFLICT_POPULATE_IMPACTED_CIS)) === 'true') {
			var conflictServices = ChangeCollisionHelper.getImpactedServicesByChangeId(chgId);
			services = (services ? new ArrayUtil().union(services, conflictServices) : conflictServices);
		}
		ciu.removeImpactedServices(chgId);
		ciu.addImpactedServices(chgId, new ArrayUtil().unique(services));

		if (userId)
			this._notifyUser(chgId, userId);
 	},
	

[/code]


As pointed out above the query is being done only on "svc_ci_assoc" table and it is not running on the Relations ship table.

As this functionality will be running Asynchronously, this function can be copied to another Script Include, which extends the OOB Script Include: "ChangeUtils".

There is a option to add code in here and you can use the same function which is available OOB and add more queries to pull the relations.

Once the script is added, you can keep using this script include until you have entry points configured for all the CI's using Service Mapping.

Once Service Mapping is implemented at full scale, then you can remove this script from the script include and let the OOB script include perform the operations.

Also, there might be performance issues depending on the scale of the relations associated to a CI, A recommendation is to do a load testing.