How Conflict records are created in Change Management

[Dibyaratnam]

Hello, please have a look at the below questions.

Q1. I want to know how Conflict records are created in the conflict table.

Q2. How does the Affected CI and Impacted services/CI related lists populate. and are these records also considered while creating conflict records for the Change. 
I am aware about the Conflict properties but I don't see any Business rule which creates conflict records on insert or update of Impacted services/CI(task_cmdb_ci_service) or Affected CI(task_ci).

 

[Mark Manders]

Conflict records aren't created when you add CIs to the impacted services list. You need to run the check yourself.

[Dibyaratnam]

So If I understood your statement correctly, Conflict records will not be created on addition of CIs to the Impacted services list and I need to manually check the conflicts from the conflict section and that will create it if there's conflict detection.

And what about the affected CI related list?

[Amitra Bhunia]

✅ Q1. How are Conflict records created in the conflict table?

Conflict records are stored in the table:
change_conflict

They are NOT created by a business rule on inserts/updates of CIs or services.
Instead, they are generated by dedicated scheduled logic, depending on the Change Management version you are using.

---

There are two mechanisms that create conflict records in ServiceNow:

---

(A) On-demand conflict check – Triggered from UI Action

When you click:

• Check Conflicts on the Change form

• Or run Check conflicts automatically (based on system properties)

ServiceNow runs a conflict detection script:

Script Include: ChangeConflictCheck

Main function: ChangeConflictCheck().run(changeSysId)

This script:

• Checks time window overlaps

• Checks CIs in the Change against other open Changes

• Checks blackout windows, maintenance windows

• Checks Impacted Services/CI

• Writes records into change_conflict table

---

(B) Scheduled Job – Background periodic check

Out-of-the-box there is a scheduled job:

Scheduled Script Execution:

"Change Conflict Detection"

This job runs ChangeConflictCheck for all changes that meet criteria:

• Not Closed

• Within conflict time window

• Conflicts enabled based on properties

This job creates AND updates conflict records.

---

✅ Q2. How do Affected CI and Impacted Services/CI related lists populate?

And do they influence conflict creation?

---

(A) Affected CIs (task_ci table)

This related list:

• Shows all CIs directly linked to the Change via Affected CIs

• Populated manually OR

• Populated through:

  • Discovery dependencies

  • CMDB relationships

  • Change requests created via incident/problem (carry forward CI)

  • Workflows / Flows / BRs depending on your org setup

There is no OOB BR that automatically creates conflicts when Affected CI is updated.

---

(B) Impacted Services / Impacted CIs (task_cmdb_ci_service table)

This related list shows:

• Business Services impacted

• Technical services via service→CI mapping

• Calculated from relationships (cmdb_rel_ci)

They populate from:

OOB Script Include:

ChangeTaskCmdbCiService

This runs during change insert/update or when a CI is added.

---

❗ Are these used while creating conflict records?

✔️ Yes — their data is used during conflict detection

But

❌ No — they don't themselves trigger conflict creation

The ChangeConflictCheck script reads:

• task_ci → Affected CIs

• task_cmdb_ci_service → Impacted Services/CIs

It compares them with:

• CIs in other Changes

• Blackout / Maintenance windows

• Change Window policies

• Dependencies & service hierarchies

But adding an Affected CI does not automatically create a new conflict record at that moment.
Conflict is only generated when:

1. You manually run conflict check

2. The scheduled job run

Please mark any helpful or correct solutions as such. That helps others find their solutions.

[Dr Atul G- LNG]

Hi @Amitra Bhunia 

Change conflict is mainly driven by the conflict properties. This means that if you enable the property, it will consider the affected CIs during conflict checks; otherwise, it only takes the main CI and the planned dates into account. In my experience, as soon as we add any CI to the ‘Affected CIs’ list and reload the page, it will consider it for conflict checking. If not, you can perform a manual check by clicking the UI action

Script Includes: