Modern Change Adoption Guide

[gregmorriso]

Autonomous IT · Zero Touch IT Support Journey

This guide walks platform administrators and change process owners through creating a custom Change Model — using Cloud Provisioning as a practical example. The first section frames Modern Change Management and its core components. The step-by-step configuration related only to change model and transitions begins in Section 3.

Custom Change Models are the primary mechanism for applying exactly the right level of change rigor to each change use case. The Cloud Provisioning model activated in this guide demonstrates the full configuration workflow.

In this guide

1. What Is Modern Change Management 2. Cloud Provisioning Model: Design Overview 3. Activating the Cloud Provisioning Change Model

4. Key Takeaways 5. Validation Checklist

1	What Is Modern Change Management

Modern Change Management in ServiceNow is the structured discipline for planning, approving, implementing, and reviewing changes to IT services and infrastructure — with embedded risk intelligence, automation, and data-driven governance. It replaces static, human-gated approval chains with a model where change risk is computed from objective operational data, approvals are dynamically generated, and process velocity is optimized.

The result is a change practice that enables faster, safer deployments — where the vast majority of changes flow through automated or delegated approval paths, and human review is reserved for the genuinely complex. Modern Change is a core prerequisite for Zero Touch IT Support maturity on the Autonomous IT journey.

1.1 Core Modern Change Capabilities

Modern Change Management spans several platform capabilities that work together across the change lifecycle:

Change Models — Purpose-built models for each delivery pattern, with pre-configured approval routing, risk parameters, and required fields. The “fit-for-purpose” model capability is the primary focus of this guide.

Change Risk Evaluation — Rule-based and AI-augmented evaluation engine that evaluates change risk using one or more independent evaluation methods.

Change Success Score (CSS) — Team-based metric that tracks historical change outcomes similar to a FICO score. High scores unlock streamlined approval paths; declining scores trigger additional oversight.

Dynamic Change Approval Policies — Risk-band-to-approval-path routing rules that ensure the approval mechanism matches computed risk — not a fixed change type. Configured separately from Change Models and applied at runtime.

Change Calendar and Scheduling — Visual interface surfacing CI maintenance windows, freeze periods, and concurrent change conflicts.

CAB Workbench — Reserved for high-risk, high-impact changes requiring collective expertise. Not a general-purpose approval queue. Effective implementations target CAB involvement in 5–15% of total change volume.

Now Assist for Change — AI-generated change descriptions, risk summaries, and implementation plan drafts. Improves record quality, which improves risk scoring accuracy downstream.

1.2 The Business Case for Custom Change Models

ServiceNow ships with OOB Preapproved (Standard), Normal, and Emergency change models — a starting point, not the destination. A mature Modern Change practice builds purpose-built Change Models for each distinct delivery pattern in the environment: a developer pushing a containerized microservice, a network engineer reconfiguring a core router, and a cloud admin provisioning infrastructure each have fundamentally different risk profiles, delivery mechanisms, and appropriate approval authorities.

Custom Change Models are the primary mechanism for applying exactly the right level of change rigor to each change use case. Each model defines its own state model, state transition rules, required fields, automated flow and risk parameters — calibrated to the specific use case. The Cloud Provisioning model activated in this guide demonstrates the full configuration workflow.

✓ Practitioner Tip: Design Change Models Around Delivery Patterns, Not Org Charts. Ask: What is the actual delivery motion (lifecycle) for this type of change, and what information do we need to make a good risk decision? Build models that reflect those answers — not models that mirror your organizational hierarchy.

2	Cloud Provisioning Model: Design Overview

Cloud Provisioning changes share a distinct risk profile: they are typically low-to-moderate risk, well-defined in scope, tooling-assisted (infrastructure-as-code, cloud console, or API-driven), and subject to cloud platform guardrails that reduce the chance of unexpected outcomes. A dedicated Change Model captures this reality in the state model and approval routing — rather than forcing cloud provisioning work through a full Normal Change lifecycle designed for complex, human-executed changes.

2.1 Abbreviated State Model

The Cloud Provisioning model uses a streamlined six-state lifecycle. States not relevant to cloud provisioning — such as the extended CAB pre-review states present in full Normal Change — are omitted. All states are mandatory; the simplified flow reduces cycle time while preserving full audit integrity.

State	Description
New	Change request created. Submitter enters description, planned start/end, and justification. Automated state transition validation checks confirm required fields.
Authorize	Dynamic Approval Policy routes based on risk score: Low → automated; Moderate → CAB; High → CAB. Approval recorded with timestamp and approver identity.
Scheduled	Change is approved and scheduled for defined change window.
Implement	Change window is open and the change is being deployed.
Review	Post-implementation review: outcomes confirmed.
Close	Change closed with outcome code (Successful / Successful with Issues / Unsuccessful / Cancelled).

✓ Why Six States? The standard Normal Change model supports additional intermediate states (e.g., PIR as a separate state, additional authorization stages) that add governance value for complex, high-risk changes. Cloud Provisioning changes are typically lower risk, tool-executed, and rollback-capable — the six-state model captures all necessary audit points without adding process overhead.

2.2 State Transition Criteria

The following criteria govern valid state transitions for the Cloud Provisioning model. These are configured as Transition Conditions on the Change Model definition and enforced by the platform — implementers cannot manually bypass them.

From State	To State	Transition Criteria
New	Authorize	All required fields populated: CI, assignment group, short description, justification, risk. Submitter manually moves to Authorize on ‘Request Approval’. Risk must be moderate or high.
New	*Implement	Approval condition met: automated approval. Planned start window is current or future. Risk is low.
Authorize	*Implement	Approval condition met (Approved by CAB requires task approval): automated approval. Planned start window is current or future.
Implement	Review	Both options (Low, Mod/High); Manual. Any tasks must be completed.
Review	Closed	Manual closure.
Authorize	Canceled	Change withdrawn/needs updates before Implement state. Automated transition.

* Indicates a flow must be set up for this transition.

3	Activating the Cloud Provisioning Change Model — Step by Step

The following steps walk through creating and activating the Cloud Provisioning Change Model on a ServiceNow instance with Modern Change Management active. Complete each step in sequence on a sub-production instance before promoting to production.

⊘ Prerequisites: The Change Management plugin (com.snc.change_management) and the Change Risk Calculator plugin (com.snc.bestpractice.change_risk) must be active before beginning. Confirm plugin status at System Definition > Plugins before proceeding.

Step 1  Navigate to Change Model Administration ⏰ 5 minutes

Open the Change Model list and create a new record. Ensure you have the correct scope, Global for this exercise. Navigate to Change > Administration > Change Models. Click New to open a blank Change Model record and configure the following: Set Name to Cloud Provisioning Verify Change Type is set to Model Verify Active is unchecked. The model remains inactive until explicitly activated in Step 6. Add a Description: Purpose-built model for cloud infrastructure provisioning changes. Abbreviated state model — risk-banded automated approval routing. Not for use with changes to existing production cloud configurations. Save the record. The model record is now created in Draft state — not yet visible to change submitters.

Step 2  Configure the State Model ⏰ 10 minutes

Define the six states for the Cloud Provisioning model. Each state is configured in the Model State sub-section of the Change Model record. On the Change Model record, locate the Model States related list (or embedded sub-form, depending on version). Add the following states in order: New (check ‘initial state’) Authorize* Implement Review* Closed Canceled For each state, configure: Label — the display name shown to users (use the values listed above exactly) Set any record presets — record presets allow for automatically set values in the request (e.g., Type = model, Assignment group = Network) Set transition conditions — specify criteria that must be met before state change ⊘ Important: Do not create and/or add new states. Additional intermediate states add cycle time without governance value for this model type. * Indicates you need to set up a flow with the transition.

Step 3  Configure State Transition Rules ⏰ 10 minutes

Transition rules enforce the exit criteria defined for each transition. Navigate to Change > Administration > Change Model > [Cloud Provisioning] > State Transitions. For each transition, create a Transition Condition record specifying: From State / To State — the state pair this condition governs Condition — a field-level condition or script that must evaluate to true before the transition is permitted. Use condition builder for simple field checks; use Script condition for compound logic. Example transition condition: New → Authorize Go to Transition Conditions and choose New Name: Mandatory fields in new state Requires: Mandatory fields (save or submit) — New > assignment_group, New > justification, New > risk, New > short_description Note: Only mark the 3 ‘Authorize’ transitions automatic for this exercise.

Step 4  Create the Dynamic Approval Policy ⏰ 10 minutes

Navigate to Change > Administration > Change Approval Policies. Create a policy for the Cloud Provisioning Change Model. This policy translates risk score bands into approval paths at runtime — no manual routing decisions required. Policy Header configuration: Name: Cloud Provisioning — Dynamic Approval Execution: Run all decisions that match Related List: Policy inputs (1) — leave as-is; should be change_request Decision 1 — Low risk auto approve: Condition (dot walk): Change request.risk IS Low Click Answer → magnifying glass → document magnifying glass → New Name: cloud prov — low risk auto approve Approval action: Approve | Approver Source: change request Table | change_request | User field (dot walk): assignment_group.manager Save, then OK and navigate back to the decision record page Decision 2 — CAB Approval (Moderate / High risk): On the Change Approval Policy record, click New on the decisions related list Name: Cloud Prov — CAB Approval Condition: (dot walk) Change request.risk IS ONE OF High, Moderate Select the magnifying glass next to ‘Answer’ and locate ‘Change approval definition: CAB Approval’ or create your own new definition. Save. ✓ Note: Set Active to false on the main approval policy record until the model is activated in Step 6. You should see 2 decision choices on the policy record before proceeding.

Step 5  Set Up the Flows ⏰ 20 minutes

✓ Live Session: Come to our Product Excellence clinic session and work with us live to set flows up. July 27, 2026.

Step 6  Activate the Change Model and Approval Policy ⏰ 5 minutes

With configuration validated on sub-production, activate the model and policy simultaneously. Navigate to Change > Administration > Change Models > [Cloud Provisioning]. Set State to Active. Save. Navigate to Change > Administration > Change Approval Policies > [Cloud Provisioning — Dynamic Approval]. Set Active to true. Save. Create a test change record using the Cloud Provisioning model. Step through all six states. Close the test change with outcome Cancelled while in state of ‘Authorize’. (Optional for Part 1)

4	Key Takeaways

The Cloud Provisioning Change Model demonstrates the core principles of Modern Change Management:

4.1 Fit-for-Purpose Change Models

Not all changes require the same level of governance. Custom Change Models allow organizations to tailor lifecycle states, required data, and approval paths to the specific delivery pattern being executed.

4.2 Risk-Based Decision Making

Approval decisions are driven by calculated risk rather than predefined change types. In this example, low-risk cloud provisioning changes are automatically approved and advanced, while moderate and high-risk changes are routed for additional review.

4.3 Automated Process Execution

By combining Change Models, Approval Policies, and Flow Designer, routine decisions can be automated while maintaining auditability and governance. This reduces cycle time, improves consistency, and allows change teams to focus attention where it adds the most value.

4.4 Governance Without Excessive Overhead

The objective of Modern Change Management is not to increase approvals — it is to apply the appropriate level of control based on risk. Automated routing ensures governance remains consistent while minimizing unnecessary manual intervention.