Synchronization between a parent and a child change.

[pavi12]

We are implementing a parent–child change model in ServiceNow and are looking for best-practice guidance.

As a Change Manager, I want to explore and validate how parent and child Change Requests should transition between states, so that Resolver teams can operate independently.

Parent - Child State synchronization

Explore how state transitions should behave when driven from the parent change:

1. When the Parent Change moves to Scheduled

• All Child Changes move to Scheduled

2. When the parent change is rejected in Authorize and moved to New state

• All child change moves to New state

Child - Parent State synchronization

Explore how child change execution should influence the parent:

1. When all child Changes moves to Authorize

• Parent Change moves to Authorize
• Child changes must not trigger CAB approvals in Authorize state. Only the Parent Change drives the CAB approval.

2. When any Child Change moves to Implementation

• Parent Change automatically moves to Implementation

3. When all Child Changes move to Review

Any guidance or examples from similar implementations would be greatly appreciated.

Thanks in advance!

Thanks,

Pavithra.

[Dr Atul G- LNG]

Hi @pavi12 

OOTB, there is no rule, logic, or script that supports this. Out-of-the-box, only incident parent-child relationships work.

If you want to implement what you’re describing, you will need to build a customization, and it’s not easy because changes involve three types:

1. Raising via model

2. Changes with approval

3. CAB/ECAB and much more.

So, to implement this fully, you will need to build the entire logic yourself.

[Dr Atul G- LNG]

Hi @pavi12 

I have worked as a Change Manager, and I would like to add a few points here.

Change management does not work like a parent–child relationship. While change-to-change mapping is possible, it should not be treated as a strict parent–child model.

Each change has its own schedule and start date. It is not mandatory that a “child” change must have the same date as another related change.

Example:
A parent change is raised to deploy an application to production.
Separate changes are raised to deploy features:

• Feature 1: Week 1

• Feature 2: Week 3

• Feature 3: Week 5

In this scenario, if the parent change goes to CAB while Feature 3 is scheduled five weeks later, it is not a good practice to validate or approve the Feature 3 change five weeks in advance.

Practically, and as per ITSM best practices, this is not a good use case. I’m happy to connect and provide more detailed clarification if needed.

---