Entering Multiple Configuration Items on a Change Request

[Craig Barclay]

Currently on our Change Request Form there is a field to enter the associated Configuration Item. This allows for just a single CI to be added.

At times a Change may affect multiple CI's.

Is it possible to make this field accept multiple CI's? If so are there any potential downstream issues?

[Omender Singh · Accepted solution]

Yes, it is possible to modify the Configuration Item field on the Change Request form to accept multiple CIs, but you need to carefully consider design, impact, and downstream effects before implementing it.

How to Make "Configuration Item" Accept Multiple CIs

1. Create a New Glide List Field:

   • Don’t directly change the OOB cmdb_ci field — it's a reference field.

   • Instead, create a new glide_list field on the change_request table (e.g., name it affected_cis).

   • Set the reference to cmdb_ci.

2. Add It to the Form Layout:

   • Go to Form Layout for Change Request.

   • Add affected_cis to the layout where you want it to appear.

3. Hide the OOB Configuration Item field (optional):

   • If you want to fully shift to multi-CI tracking, consider removing or hiding the original field to avoid confusion.

Downstream Considerations

Before you roll it out, understand these:

❗ Potential Issues:

Area Concern

Workflows / Approvals	Many workflows are built assuming only one CI. Multi-CI can cause logic gaps unless updated.
Impact Analysis	OOB Impact Analysis only looks at the cmdb_ci field. You’ll have to customize to analyze each CI in the new glide_list.
Change Task Generation	If tasks are generated per CI, you'll need to loop through the list and create them dynamically.
Reports / Dashboards	Any CI-based reporting on Change will need updates to query the new glide_list field.
Integrations	Any 3rd-party tool or integration pulling CI data from Change might break or show incomplete data if they look for only cmdb_ci.

---

 

Safer Alternative Approach (Recommended)

1. Keep the single CI field for backward compatibility.

2. Create a related list (many-to-many relationship) using a child table like change_ci_mapping or a custom table with:

   • Change Request reference

   • Configuration Item reference

3. Advantages:

   • Better normalization.

   • Easier to extend for task generation, notifications, impact assessments.

   • Won’t conflict with OOB logic.

---

Example: How the Many-to-Many Table Works

Field Value

Change Request	CHG0010059
CI	Email Server
CI	Load Balancer

You can link this list as a Related List on the Change Request form.

[Dr Atul G- LNG]

Hi @Craig Barclay 

I worked as a Change Manager, and this is a very common issue. Out of the box (OOTB), you can only enter one CI on the change form, while the rest can be manually added to the affected CI or impacted services release list. It’s not recommended to enter multiple CIs in the change form because doing so would require changing the entire design, including modifying data types and customization. The best approach is to add multiple CIs to one of the related lists. Please avoid any customizations for this.