Parent Change Request Schedule Date Change Not Cascading to Change Tasks – Conflict Issues

[Sunayana4]

Hi All,

We’ve noticed a recurring issue in our Change Management process: When the Planned Start Date or Planned End Date is updated on the parent Change Request, the associated Change Tasks do not automatically update to match the new schedule.

This often leads to schedule conflicts in the Change Request table, because the parent’s dates are now different from its tasks. The conflict detection engine still flags the parent, even though the intent was to shift the entire change window.

Questions:

1. Is this the expected out‑of‑the‑box behavior in ServiceNow?

2. If so, is there a recommended permanent fix to cascade date changes from the parent to all

3. related change tasks automatically?

4. Has anyone implemented a Business Rule or Flow Designer solution for this, and could you share an example?

We’re looking for a solution that:

• Updates all related change tasks when the parent’s planned dates change

• Avoids creating schedule conflicts in the Change Request table

• Works reliably without breaking workflows or audit history

Any guidance, best practices, or sample scripts from the community would be greatly appreciated.

Thank you,

Sunayana

#change_management #change_request #change_task #planned_dates##conflict_detection #business_rule #flow_designer

[Dr Atul G- LNG]

Hi @Sunayana4 

Questions:

1. Is this the expected out‑of‑the‑box behavior in ServiceNow?

Atul:Yes, this is the expected behavior. A change is not the same as an incident, where the parent comment or details are passed to the child incident. In this case, there is no out-of-the-box (OOTB) logic that handles this.

1. If so, is there a recommended permanent fix to cascade date changes from the parent to all

Atul:

I would recommend not doing this. The reason is that a parent change typically acts as an umbrella that holds the overall change context. If you assign the same planned dates to both the parent and all child changes, it implies that every change needs to be executed at the same time—which is usually not a good practice.

Let me give you an example from my experience as a Change Manager:
We were doing a data center migration project that spanned over two months. We had a parent change covering the entire migration period, and every week we deployed individual child changes. The parent change had planned dates spanning the full two months, but each child change had its own specific time window based on the task it was performing.

This approach allowed us to track the overall change effort while maintaining precise control over each deployment.
So again, I suggest avoiding assigning identical planned dates to both parent and child changes unless absolutely necessary.

1. related change tasks automatically?

Atul: 

Each change has its own workflow, and once a change reaches a certain state, the associated tasks are created automatically.

Are you trying to pass tasks from the parent change to the child changes?

1. Has anyone implemented a Business Rule or Flow Designer solution for this, and could you share an example?

Atul: Lets see what process say.