CIS-ITSM Exam

[sn-ushi]

What is recommended to do if you incorrectly classify an emergency change as a normal change during the creation and scope stage of the change?

•  Cancel and recreate the change as an Emergency change
•  Tick the CAB approval required checkbox
•  Create an emergency change and link them as parent-child
•  Select Revert to New and update the type to Emergency

[SAI VENKATESH]

Hi @sn-ushi 

You need to cancel the change you created wrongly and recreate the change as Emergency change.

Answer: 

•  Cancel and recreate the change as an Emergency change

Thanks and Regards

Sai Venkatesh

[AnkaRaoB]

During the Creation and Scope stage of a change in ServiceNow Change Management, a change is mistakenly classified as a Normal change when it should have been an Emergency change.

Recommended Action

The recommended and best-practice approach is to:

Revert the change to the New state and update the Change Type to Emergency.

This allows the same change record to be reused while correcting the classification.

Why This Is Recommended

• Preserves the original change record
• Maintains audit history and traceability
• Keeps attachments, relationships, and references intact
• Aligns with ServiceNow change management best practices

Why Other Options Are Not Recommended

• Cancel and recreate the change
  This results in lost history and unnecessary duplicate records.
• Tick the CAB approval required checkbox
  This does not convert the change into an Emergency change.
• Create a new emergency change and link them as parent-child
  This adds unnecessary complexity and is not intended for correcting misclassification.

If this response helps you solve the issue, please mark it as the Accepted Solution

[Its_Sagnic]

Hi @sn-ushi ,

If you incorrectly classify an emergency change as a normal change during the 

Creation and Scope stage (the "New" state), the recommended action in ServiceNow is:

4. Select Revert to New and update the type to Emergency 

In ServiceNow's Change Management lifecycle, the "New" state is part of the initial Creation and Scope stage. Here is why option 4 is the preferred approach: 

• State-Specific Capability: While a change is in the "New" state, the record is still being drafted. If the state has not yet advanced to Authorize or Assess, you can often simply update the type. If the workflow has already been triggered, selecting Revert to New resets the state, allowing you to modify the Type field.
• Workflow Alignment: Changing the type at this early stage ensures the correct state model and workflow (e.g., bypassing standard CAB for eCAB) are applied to the record moving forward.
• Data Integrity: Reverting and updating is more efficient than canceling and recreating (Option 1), as it preserves the information already entered in the record (Description, Configuration Items, etc.) without creating a "Canceled" record that might clutter audit logs.
• Process Compliance: Options like simply ticking a checkbox (Option 2) do not actually change the underlying Change Type, meaning the record would still follow the incorrect technical lifecycle for a Normal change instead of the expedited Emergency path. 

If you find the solution useful for you please mark it as helpful and please accept the solution.

Regards,

Sagnic

[sn-ushi]

Thank you! But how do you Select Revert to New? In my PDI I do not see this option.