Baseline Change Management Normal Model

Svetozar Stojanovic PFP Svetozar Stojanovic
31. Januar 2023 1106 Wörter 426 Ansichten betont
ServiceNow Change Management Normal Model
Normal Change Model State Diagram

Today I am going to explain the baseline behavior of Normal type Changes in ServiceNow Tokyo version. My motivation for writing this article is that I have not found good explanation during studying for CIS ITSM exam for intricacies involving state transitions for all change models, not just for the Normal change model. So, I went to my small whiteboard and began drawing.

Navigation

All Change models are accessible through navigation bar on the left using: Change > Administration > Change Models. These are top-level Change Model [chg_model] records that include further references to model states that are represented by rounded rectangles above.

You may access the same table directly by using chg_model.LIST in the navigation bar to open it in a new tab, or chg_model.list to open it in the existing tab.

About Normal Model

What separates Normal change model compared to other change models is the highest amount of states that it has under its belt. You can, of course, add even more states according to your organizational needs but it's recommended to stick with baseline Normal change model if you are planning on facilitating changes of ITIL Mode 1 and you need an approval of either the technical SMEs and/or Change Advisory Board (CAB).

Model States

Let's look at a the model states for the Normal change model:

  1. New - this is the starting point for all change requests upon creation.
  2. Access - second step in the flow of change requests requires approval from the group that is set as the Assignment group on change request record.
  3. Authorize - next step requires approval from CAB but not in all cases as we will see shortly.
  4. Scheduled - the change request is scheduled for implementation in this phase.
  5. Implement - represents the state of work in progress for change tasks, i.e. implementation of changes.
  6. Review - upon implementation of change tasks.
  7. Closed - state for the change that has been implemented successfully and the process of closing is documented.
  8. Canceled - state for unsuccessful/abandoned changes.

States New, Closed and Canceled are marked in black because Closed and Canceled are the end states and New is the starting state. These states are common to few other change models.

Model State Transitions and Conditions

Equally important as the change model states are the state transitions which regulate how the movement between states is defined using state transition conditions. Transitions themselves are referenced in the related list of model state records and include references to transition conditions which are evaluated when state is changed.

State transitions can either occur automatically or manually by clicking on UI actions at the top of the change request form or by saving the record with altered state. We can see a clear separation on the diagram at the top of this article with automatic transitions being above the states and manual ones below the states.

Below is the table containing states, state transitions and their conditions explained.

State Transition State Transition Condition(s) Automatic
New --> Assess Assignment group is NOT empty No
Assess --> New - No
Assess --> New Rejected by Assignment Group Yes
Assess --> Authorize Approved by Assignment Group Yes
Authorize --> New Rejected by CAB Approval Yes
Authorize --> Scheduled Approved by CAB Approval Yes
Scheduled --> Implement Not On hold No
Implement --> Review Not On hold No
Implement --> Review No active Change Tasks Yes
Review --> Closed Not On hold Mandatory Close Code and Close Notes No
(any) --> Canceled - No

Next, let's examine change approval policy definition for the Normal change model.

Normal Change Approval Policy

The Normal Change Approval Policy dictates the approval process and movement between New, Assess and Authorize states.

This approval policy has two inputs: the change request record and whether the assignment group manager for the change request has already approved the change request.

There are three decisions based on these inputs:

  • Assess Technical Approvals - this approval policy decision is for the Assess state and triggers a group approval action for the Assignment group.
  • Requires CAB Approval - this policy decision acts in the Authorize state and triggers a CAB approval request (first response) based on the following conditions:
    • Risk is between Moderate and High,
    • OR
    • Assignment group is empty.
  • Low Risk Manager approval - in case of a Low Risk and manager has not already approved the change.

Normal Change Flows and Actions

There are three flows which facilitate the progression of Normal change model states, e.g. Normal change requests.

  1. Change - Normal - Assess
  2. Change - Normal - Authorize
  3. Change - Normal - Implement

The first flow Change - Normal - Assess does two things in parallel:

Flow trigger is a change request record of State is Assess, model is Normal, created or updated and which is not On hold (this is a boolean field on the change request record).

  1. applies the Normal Change Approval Policy explained above using the Apply Change Approval Policy action.
    • if the approval is skipped (e.g. low risk change approved by the manager), the change request's field Approval is set to Approved.
    • Evaluate Change Model baseline flow action is executed. This action automatically moves the change request state according to the state transitions if the state transition conditions evaluate to true.
    • In case of a rejection by the assignment group, a notification is sent to the Requested by, informing the person that the change has been rejected.
  2. waits for the On hold field is true OR Active is false OR State is New.
    • disregards already sent out approval requests.

The Change - Normal - Authorize flow does the does the similar thing but with a tweak:

  • Flow trigger is a change request record of State is Authorize, model is Normal, created or updated and which is not On hold (this is a boolean field on the change request record).
  • First the flow checks if the Assignment group manager has already approved the change request. This is then supplied to the Apply Change Approval Policy action's second parameter.
  • every other step is identical to the Change - Normal - Assess flow.

The last flow Change - Normal - Implement does the following in parallel for change requests in State Implement:

  1. Waits for the change of state to Review
    • Cancels Change Tasks created from flow
    • Evaluates Change Model
  2. Executes subflow Change - Implementation tasks
    • Evaluates Change Model

The subflow Change - Implementation tasks creates two change tasks:

  1. Implementation
  2. Post Implementation

Closing words

This article was an overview of the Normal change model and I hope it helped you understand the interplay between change models, change states, state transitions, state transition conditions, and change approvals for the Normal change model, as well as which role do the flows play in evaluating change model states.