There are three types of changes:

1. Standard Change: a pre-authorized change that is low risk, relatively common and follows a specified procedure or work instruction.

2. Normal Change: follows the complete change lifecycle. It needs approvals and must be planned well ahead of time. It usually has a significant impact on business processes and IT workflows.

3. Emergency Change: a change that must be implemented as soon as possible, for example to resolve a major incident or apply a security patch. It is so urgent that it bypasses the usual group and peer review and goes straight to authorization by the Emergency CAB (ECAB).

ServiceNow largely follows ITIL for its change management process. A Normal change moves through these states:

1. New: a need for a change is identified and the change request is raised.

2. Assess: the change is reviewed by the people who govern the process (peer review and technical approval), and it is accepted or rejected.

3. Authorize: impacts, benefits and risks are reviewed by the stakeholders who will be affected. For high-impact changes, the Change Advisory Board (CAB) is also consulted.

4. Scheduled: the change is scheduled so that it does not disrupt work, ideally inside a maintenance window.

5. Implement: with approvals and the schedule in place, the change is carried out.

6. Review: the implemented change is verified to confirm it works as intended and did not break anything (Post Implementation Review).

7. Closed: the change is closed with a close code such as Successful, Successful with Issues or Unsuccessful.

8. Canceled: a change can be canceled at any stage if it is no longer needed. The reason is recorded in the work notes.

Note: Standard changes skip Assess and Authorize because they are pre-approved, and Emergency changes use a faster ECAB approval. Mentioning this nuance scores extra points.

The Change Advisory Board (CAB) is a group of people who assess, authorize and prioritize changes and keep control of the change process. It typically includes the Change Manager, service and application owners, technical architects, and business representatives who understand the impact of a change.

CAB reviews Normal changes (especially high-risk ones) before they are authorized: the implementation plan, the backout plan, the risk, the timing and possible conflicts with other changes. For urgent changes that cannot wait for the next CAB meeting, a smaller Emergency CAB (ECAB) gives a quick approval.

Post Implementation Review (PIR) is the formal review after a change has been implemented. It is part of the Review state in the change lifecycle.

The Change Manager and stakeholders check whether the change achieved its expected outcome, whether it caused unintended issues, whether the backout plan had to be used, and whether the implementation followed the documented plan. The change is then closed as Successful, Successful with Issues, or Unsuccessful.

Why it is important:
- It captures lessons learned for future changes.
- It shows which repeated, successful changes could become Standard changes.
- It feeds Problem Management when a failed change causes incidents.
- It makes the risk assessment more accurate over time.

Both are time windows defined on schedules, but they do opposite jobs.

Maintenance Window: an agreed time slot when changes are allowed on a CI or service, usually outside business hours (for example, Sunday 2 AM to 6 AM). It is typically linked to the CI.

Blackout Window: a period when changes are not allowed, used to protect critical business periods such as financial close, peak sales or a major launch. It can apply to a CI, a service or the whole instance.

When a change is scheduled, ServiceNow checks both: the planned dates should fall inside a maintenance window and must not overlap a blackout window. A blackout overlap is flagged as a conflict.

Conflict Detection checks whether a scheduled change clashes with other changes or schedules, based on the change's CIs and its planned start and end dates. It needs Planned Start, Planned End and at least one CI. It can run on save or from the "Check Conflicts" action.

Typical conflicts it finds:
1. Another change on the same CI at an overlapping time.
2. The change falls inside a blackout window.
3. The change falls outside the CI's maintenance window.
4. Changes on related parent or child CIs, based on CMDB relationships.

The result is shown in the Conflict Status field (Not Run, No Conflict, Conflict) with the details in the conflicts related list.

Note: Conflict Detection follows CMDB relationships, so it is only as good as the CMDB. Connecting Change Management with CMDB health is a strong point in interviews.

This is the classic case for turning a repeated, low-risk Normal change into a Standard change.

1. Check the history: look at the last several monthly patching changes. If they were consistently successful and caused no incidents, the activity qualifies.

2. Create a Standard Change Template proposal from the Standard Change Catalog, with the implementation plan, a tested backout plan, assignment group and low risk.

3. CAB approves the proposal, and it becomes a published template.

4. From then on, the team raises the change from the template. It is pre-approved, so it skips Assess and Authorize and goes straight to Scheduled and Implement.

Note: Mention governance: review the template periodically to confirm it is still low risk. "Convert it and forget it" is a red flag for interviewers.

This is an Emergency change. The deadline does not allow waiting for the next CAB.

1. Raise an Emergency change with the justification (for example, an actively exploited vulnerability), the affected CIs, the planned start and end inside the 4-hour window, and the implementation and backout plans.

2. The Change Manager convenes the Emergency CAB (ECAB): a small group such as the Change Manager, service owner, security lead and a senior technical lead, usually on a quick call.

3. ECAB weighs the risk of not patching against the risk of patching without full testing, and records the approval on the change.

4. Implement and monitor closely.

5. Still do the Post Implementation Review, and report the emergency change at the next regular CAB so governance stays transparent.

Use the Change Management REST API (namespace sn_chg_rest) rather than inserting into change_request with the Table API.

The Change API creates the change through the change model, so the right type, defaults, state model and approval behaviour are applied. A raw Table API insert just writes a row and can skip all of that.

For deployments that repeat with the same low risk, create them as Standard changes from an approved template, so they are pre-approved and don't wait for CAB.

// Normal change
POST https://<instance>.service-now.com/api/sn_chg_rest/change/normal
{
  "short_description": "Deploy payments-api 2.14.0 to production",
  "cmdb_ci": "<sys_id of the service CI>",
  "start_date": "2026-10-20 18:30:00",
  "end_date": "2026-10-20 19:30:00"
}

// Standard change from an approved template
POST https://<instance>.service-now.com/api/sn_chg_rest/change/standard/<template_sys_id>

Note: Use an integration user with only the roles it needs, store the returned change sys_id in the pipeline, and update the same change later (to Implement, then Review and Closed) instead of creating a new one on every retry.

Two windows overlap when each one starts before the other one ends. Run it as a before update Business Rule on change_request with the condition "State changes to Scheduled", exclude the change itself, and let the query do the filtering:

(function executeRule(current, previous) {
    var ciId = current.getValue('cmdb_ci');
    var start = current.getValue('start_date');
    var end = current.getValue('end_date');
    if (!ciId || !start || !end) {
        return;
    }

    var otherGr = new GlideRecord('change_request');
    otherGr.addActiveQuery();
    otherGr.addQuery('sys_id', '!=', current.getUniqueValue());
    otherGr.addQuery('cmdb_ci', ciId);
    otherGr.addQuery('start_date', '<', end);   // the other change starts before this one ends
    otherGr.addQuery('end_date', '>', start);   // and ends after this one starts
    otherGr.setLimit(1);
    otherGr.query();
    if (otherGr.next()) {
        gs.addErrorMessage('The planned window overlaps ' + otherGr.getValue('number') + ' on the same CI.');
        current.setAbortAction(true);
    }
})(current, previous);

Follow-up: "Now check the Affected CIs too." Don't query once per CI. Collect the CIs from task_ci in one query, find the other changes that share any of them in a second query, then check the windows in a third:

var changeId = current.getUniqueValue();
var ciIds = [current.getValue('cmdb_ci')];
var mineGr = new GlideRecord('task_ci');
mineGr.addQuery('task', changeId);
mineGr.query();
while (mineGr.next()) {
    ciIds.push(mineGr.getValue('ci_item'));
}

// other tasks that share any of these CIs
var otherIds = [];
var sharedGr = new GlideRecord('task_ci');
sharedGr.addQuery('ci_item', 'IN', ciIds.join(','));
sharedGr.addQuery('task', '!=', changeId);
sharedGr.query();
while (sharedGr.next()) {
    otherIds.push(sharedGr.getValue('task'));
}

// one query for overlapping active changes among them
var clashGr = new GlideRecord('change_request');
clashGr.addActiveQuery();
clashGr.addQuery('sys_id', 'IN', otherIds.join(','));
clashGr.addQuery('start_date', '<', current.getValue('end_date'));
clashGr.addQuery('end_date', '>', current.getValue('start_date'));
clashGr.setLimit(1);
clashGr.query();

Note: ServiceNow also has built-in Conflict Detection for this. Interviewers ask the scripted version to see whether you can write overlap logic and avoid queries inside loops.

Keep the rules declarative and make the approvers dynamic, instead of hard-coding approvals in Business Rules.

1. Decide by risk: in newer releases, use Change Models with Change Approval Policies, where each decision row maps a condition (for example, risk is High) to the approvals it needs. On older setups, a Flow (or workflow) with an If on risk does the same.

2. CAB: a group approval for the CAB group on the high-risk path.

3. CI owners: the approver groups come from the affected CIs, so collect them at run time and de-duplicate:

// Script for the dynamic approval step: managed-by groups of all affected CIs
var groupIds = {};
var affectedGr = new GlideRecord('task_ci');
affectedGr.addQuery('task', changeSysId);
affectedGr.addNotNullQuery('ci_item.managed_by_group');
affectedGr.query();
while (affectedGr.next()) {
    groupIds[affectedGr.ci_item.managed_by_group.toString()] = true;
}
return Object.keys(groupIds);   // one approval per group, even if it owns several CIs

4. Low risk: a single approval for the assignment group's manager.

Note: Why not a Business Rule that inserts sysapproval_approver records? It hides process logic in code, is easy to break when the approval rules change, and is hard for the change team to read. Policies and flows can be changed by process owners and are visible on the change.