ITSM : Change

[stephendarl]

We're considering automating the transition from scheduled to the implement phase of change based on the planned start date / start of the change window.  In addition, we're also considering preventing that transition to implement outside of/prior to the authorised change window. 

There are benefits of applying both of above from a control perspective but i'm also conscious that somewhere this may have been implemented/attempted and we're keen to learn from wider community experience/good practice.  Any experiences or benefits/pitfalls to share?

[Marcos Kassak · Accepted solution]

Hi @stephendarl,

In most of the environments that I've worked with, change implementers rarely start execution exactly at the planned start of the authorized window. Dependencies, pre-checks, resource timing, or waiting for external confirmation often cause implementation to start slightly earlier or later. If SN automatically transitions based on the planned start date, you risk misalignment between what’s happening operationally and what’s reflected in ServiceNow. That misalignment quickly impacts reporting accuracy, audit trails, and change success metrics.

Preventing manual movement to Implement outside of the window can also cause unnecessary blockers. For example, if a team gets early approval to begin 30 minutes before the planned start or needs to handle a dependency that shifts the timeline, the automation would stop them from progressing, forcing manual overrides or emergency exceptions. Over time, those workarounds reduce trust in the process.

The strongest implementations I’ve seen don’t enforce the transition automatically but assist it. For example:

1) Send a notification thru a Teams integration/email when the window opens, prompting the implementer to take action.

2) Use a logic to validate that Actual Start and Actual End times fall within the approved window and alert if they don’t. You can configure Change Success Score metrics here to know which groups are often doing this and lower their score.

3)Flag exceptions after the fact rather than blocking progress in real time.

That combination gives you the control and visibility you’re aiming for, without disrupting delivery or introducing noise in your reports. But if you do have an Enterprise Change Management team that does not really care about metrics/data and this automation would help them gain some time on their day, it's all about the pros and cons and taking those tradeoffs where it matters.