on change form CI

[Vaibhav Ramteke]

Hello,

I developed when user select class and location dependent CI appear as well as if only select class that case also that class related ci appear.
if only select location then only dependent ci appear if select both then class,location appear but 
what if in change multiple CIs with different locations How would this be captured

 

[Vaibhav Ramteke]

what if in change multiple CIs with different locations How would this be captured  this is query

[vaishali231]

Hey @Vaibhav Ramteke 

This is an important edge case and should be handled based on the organization's Change Management process.

In my implementation, the CI reference qualifier works as follows:

If only Class is selected, it displays all CIs belonging to that class.

If only Location is selected, it displays all CIs for that location.

If both Class and Location are selected, it displays only the CIs matching both conditions.

However, the scenario changes when a Change Request contains multiple CIs from different locations.

Here, there is no single location that can be used as the filter because the selected CIs belong to multiple locations.

 

Approach 1: Allow Multiple Location

Instead of filtering by a single location, collect all unique locations from the selected CIs and modify the qualifier to use an IN condition.

Example:

Class = Server

Location IN (New York, London)

This allows users to continue selecting CIs from any of the already represented locations.

Approach 2: Enforce a Single Location per Change

If the organization follows a policy that a Change Request should impact only one location, validate the selection and prevent users from adding CIs from different locations.

Example validation:

Selected CI belongs to London.

Existing CIs belong to New York.

Display error:

"All Configuration Items in this Change must belong to the same location."

Approach 3: Ignore Location After the First CI Selection

Once the first CI is selected, use the locations of all selected CIs to build the qualifier dynamically.

Example:

Initially:

Class = Server

Location = New York

After adding a London server:

Class = Server

Location IN (New York, London)

This expands the available list as additional locations are introduced.

Approach 4: Create Separate Changes Automatically

If the organization requires strict location isolation, automatically create one Change Request per location.

Example:

CR001 -> New York CIs

CR002 -> London CIs

CR003 -> Singapore CIs

This is commonly used in organizations where CAB approval, maintenance windows, or implementation schedules are managed separately for each site.

*********************************************************************************************************

If this response helps, please mark it as Accept as Solution and Helpful.

Doing so helps others in the community and encourages me to keep contributing.

Regards

Vaishali Singh

Servicenow Developer
Linkedin - https://www.linkedin.com/in/vaishali-singh-2273361bb

[Abhishek Pal]

Hi @Vaibhav Ramteke ,

For a Change Request, the Configuration item field is designed for one primary CI. It should not be converted into a multi-select field to capture several CIs from different locations.

Use the OOB Affected CIs related list for this requirement.

Recommended approach:

1. Keep Configuration item as the primary CI for the change.

2. Add the Affected CIs related list to the Change Request form if it is not already visible.

3. In the Affected CIs related list, select Add.

4. Filter the available CIs using both conditions:

Class is <required CI class>
Location is <required location>

5. Select the required CIs and click Add Selected.

6. Repeat the process for the other classes and locations.

For example:

Server Class + Noida Location
-> Add the required servers

Database Class + Mumbai Location
-> Add the required databases

Network Gear Class + Hyderabad Location
-> Add the required network devices

All selected CIs will be associated with the same Change Request through the Affected CIs relationship.

There is no requirement for one Location field on the Change Request to represent all selected CIs. Each CI already contains its own Location value.

If the CIs at different locations require separate implementation activities, assignment groups, schedules, or owners, create separate Change Tasks for each location and associate the relevant CIs with the appropriate task.

Recommended data model:

Change Request
-> Primary Configuration Item

Affected CIs
-> All additional CIs impacted by the change

Change Tasks
-> Separate implementation work by location, team, or activity

Avoid creating custom comma-separated CI fields or manually storing multiple CI sys_ids. The OOB Affected CIs related list is scalable, reportable, and supported by Change Management features such as conflict detection and impacted-service calculation.

Also note that OOB Change Management allows Affected CIs to be added while the Change Request is in the New state, so verify the current state during testing.

Reference:

https://www.servicenow.com/docs/r/it-service-management/change-management/c_AffectedCIsAndImpactedSe...

Hope this helps!

If this response helped, please mark it as Helpful.
If it resolves your issue, please Accept it as Solution.

Kind Regards,
Abhishek Pal