---
sourceDocument: Zurich IT Service Management
sourceDocumentLink: https://www.servicenow.com/docs/r/zurich/it-service-management

 Release :

    - zurich

ft:locale :

    - en-US

ft:publication_title :

    - Zurich IT Service Management

ft:clusterId :

    - itsm

bundleId :

    - itsm

workflow :

    - Technology


---

# Unauthorized change request

# Unauthorized change request {#ariaid-title1}

Release version: Zurich  
Updated July 31, 2025  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## 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 full answer 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.  
Note:  
Unauthorized change requests are created only for the CIs that are part of the application services. Also, there is a flapper algorithm that uses a learning pattern to minimize false positives.

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.  
The learning pattern identifies the false positives as follows:

1. When a CI property associated with a service changes, the new value (CI and field pair) is logged in the flapper's data table.
2. The system runs a nightly job and executes various algorithms on the data that is collected to identify patterns that point to false positives.
3. 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.
{#unauthorized-change-request__ol_snx_hbp_jkb}  
An unauthorized change request is created when an unplanned CI change activity occurs, and the system triggers the following checks:

* 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.
{#unauthorized-change-request__ul_hzt_kks_whb}

The ci.change.unplanned event that is generated automatically triggers
the creation of an Emergency type change request.  
With the help of the following details that are pre-populated on the form, you can identify and review the unauthorized change:

* 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.
{#unauthorized-change-request__ul_vzh_52f_xhb}  
An email notification is sent to the Assignment group, CI Item managed by, Owned by, and Assigned to members for review and approval. However, if there are many CI changes and there are no open change requests created to include the CIs, the system creates unauthorized change requests on these CIs. When this event occurs, the members receive numerous unauthorized change notification emails. In such a case, you can choose to disable these notifications. For more information, see [Disable unauthorized change
notification](https://www.servicenow.com/docs/aQFm2Hxj_iVQpAYhzlLAzw "You can choose to disable the generation of unauthorized change requests that you receive on any unauthorized change event. When a configuration item (CI) that is part of an application service is updated, the system identifies this update and verifies whether the updated CI is part of an open change request.").  
Note:  
Email notifications are sent only when there is an unplanned change on the CI that is part of an application service (discovered or manual service).

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 {#unauthorized-change-request__section_swz_b3s_whb}

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 {#unauthorized-change-request__section_f5n_xls_whb}

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 <kbd class="ph userinput">Outage</kbd>. For more information, see [Create an outage from a
task](https://www.servicenow.com/docs/OqtfK7QC_NH6lrv00uCvtQ "Create an outage from a task record to understand the down time of a configuration item.").  
Note:  
When there is an unauthorized change without an outage record associated, then the state flow moves from Authorize to Review and skips the schedule or implement state. The state changes because the implementation has already happened for this change.
* **[Disable the creation of an unauthorized change request](https://www.servicenow.com/docs/aQFm2Hxj_iVQpAYhzlLAzw)**   
  You can choose to disable the generation of unauthorized change requests that you receive on any unauthorized change event. When a configuration item (CI) that is part of an application service is updated, the system identifies this update and verifies whether the updated CI is part of an open change request.
* **[Unauthorized change properties](https://www.servicenow.com/docs/YBTgtlkL0Qq2e~9z~Crn7A)**   
  Use the Unauthorized Change Properties page to enable or disable the unauthorized change capability, and to configure the criteria for additional unauthorized change properties.

**Related tasks**   

* [Create a change request from a configuration item (CI)](https://www.servicenow.com/docs/MTtjta1WNaa2anZlDYjtMw "Create a change request from a list of configuration items (CIs), or add selected CIs from a list to a change record.")
* [Create a standard change request from the catalog](https://www.servicenow.com/docs/~~zxVXKQPFD9KsU5m7nCvg "You can create a standard change request from the published standard change catalog templates.")
* [Copy a change request](https://www.servicenow.com/docs/v80VnAUmqlNaK2oayhIalA "You can copy details of an active or canceled change request to a new change request.")
* [Create a change task](https://www.servicenow.com/docs/Am_fEIgQpmA4E1nlV1Tgeg "You can create change tasks for a change request. A change task is a piece of work related to the change request. For example, there can be tasks to plan the change, implement the change, and test, and review the work.")