Unauthorized change request
Summarize
Summary of Unauthorized change request
This functionality within ServiceNow's Change Management application integrates with Service Mapping and ITSM to detect and manage unauthorized changes to configuration items (CIs) that are part of application services. When an unauthorized change is detected, an emergency unauthorized change request is automatically created to enable timely review, approval, or rejection of the change.
Show less
How Unauthorized Changes Are Managed
- The system detects unplanned changes on CIs and triggers the creation of an emergency unauthorized change request linked to that CI.
- Only CIs within application services are monitored for unauthorized changes.
- A flapper algorithm with a learning pattern minimizes false positives by identifying non-significant changes, such as measurement errors or case sensitivity differences, to avoid unnecessary emergency change requests.
- The algorithm collects CI property changes, runs nightly analyses to detect false positives with over 90% confidence, and suppresses alerts unless the CI is currently part of an active change request.
Unauthorized Change Request Workflow
- The system verifies whether the CI belongs to an allowed class and checks prior flags within a notification ignore period before raising a new unauthorized change event.
- Upon event detection and if event processing is enabled, an emergency type change request is created with key fields pre-populated (e.g., Unauthorized option selected, Assignment group set to Change Management, CI identified, and description of changes included).
- Email notifications are sent to relevant stakeholders such as the Assignment group and CI owners to prompt review and approval.
- To prevent notification overload when many unauthorized changes occur without open change requests, notification emails can be disabled.
- After approval, the change request moves to the Review state to continue the standard change management process.
Post-Implementation Review
For unauthorized changes implemented without prior approval, a post-implementation review task is assigned to the Change Management group. This task facilitates evaluation of risks and impacts and is tracked with a Review state until closure.
Modifying Unauthorized Change Requests
- Change managers can convert an unauthorized change request to an emergency change request by clearing the Unauthorized checkbox and documenting the reason in Work notes.
- ITIL users can clear the checkbox by creating an outage record linked to the task.
- If no outage record is associated, the change request state moves directly from Authorize to Review, bypassing schedule and implementation steps due to the change already being implemented.
Disabling Unauthorized Change Requests
Organizations can disable the creation of unauthorized change requests entirely through configuration settings if desired. This allows control over when and how unauthorized changes are flagged and managed.
Configuration and Properties
The Unauthorized Change Properties page enables administrators to activate or deactivate unauthorized change detection and set criteria for additional related properties, tailoring the process to organizational needs.
Practical Benefits for ServiceNow Customers
- Automates detection and management of unplanned changes to critical CIs within application services.
- Reduces false alerts through machine learning to focus attention on real risks.
- Ensures timely communication and review by relevant stakeholders via pre-populated change requests and notifications.
- Supports governance processes with post-implementation reviews and the ability to modify change classification.
- Offers flexibility to disable or customize unauthorized change handling to fit operational requirements.
Understand how an unauthorized change activity on a configuration item (CI) is captured and managed, so that you can review and take timely action on this change.
As part of the ServiceNow® Service Mapping integration with ServiceNow® ITSM, the Change Management application receives an event notification when an unauthorized change activity is detected. As a result, an emergency unauthorized change request is created for the relevant CI. You can review and approve or reject the unauthorized change from the Change Management application.
At times, the discovery process (horizontal or top-down discovery) identifies a change on a CI property that may not be an actual change by definition. This identification is due to a measurement error or just a different representation of the same value, such as case sensitivity. The learning pattern identifies the false positives (flapper changes) and prevents triggering the recomputation and time-line updates as an emergency change request is a critical action. You want to avoid false positives and report only real changes.
- When a CI property associated with a service changes, the new value (CI and field pair) is logged in the flapper’s data table.
- The system runs a nightly job and executes various algorithms on the data that is collected to identify patterns that point to false positives.
- The system runs all the relevant strategy predicates for the changed CI fields with a
confidence level greater than 90%. This step determines whether all the new values are
false positives or not. If all the new values are false positives, then the change is
ignored, and the model is not updated.Note:If the CI is associated with an active change request, then this step is skipped.
- The system checks to see if the CI is part of the allowed CI classes. If it is allowed, then the system checks to see if this specific CI has been flagged previously. If it was flagged and the previously created unauthorized change was within the notification ignore period, then no further action is taken. If not, then further checks are made to see whether this CI is associated to a change request that matches the condition stated in the properties. If not, then the change to the CI that was detected is flagged as unauthorized and a ci.change.unplanned event is raised.
- On receipt of the ci.change.unplanned event, the script checks to see if the Enable event processing field is true. If it is true, then an unauthorized change request is created. By default, this property is false.
The ci.change.unplanned event that is generated automatically triggers the creation of an Emergency type change request.
- The Unauthorized option is selected. This option indicates that the change is an unauthorized change.
- The Assignment group field is populated with Change Management.
- The Configuration item field is populated with the item that the unauthorized change was made for.
- The Description field is populated with the information on the changed fields of the change request.
After this change request is approved, the state changes to Review and the regular process is followed to close the request.
Assign post-implementation review
When a change is implemented without approval, post-implementation review is necessary to evaluate the risk and impact of the unauthorized change.
After the unauthorized change is approved, a change task is created with State field as Review. This change task is assigned to the Change Management group with the Short description field as Post Implementation Review. The assigned members who receive the notification can review and close the change task.
Modify the unauthorized change setting
As a change manager, you can clear the Unauthorized check box to convert the unauthorized change request to an emergency change request. When you clear the check box, enter the reason for this modification in the Work notes field.
If you are an ITIL user, clear the Unauthorized check box by creating an outage from the task record with the Type field specified as Outage. For more information, see Create an outage from a task.