Unauthorized change request

  • Release version: Yokohama
  • Updated January 30, 2025
  • 4 minutes to read
    • Summarize
    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 feature integrates ServiceNow® Service Mapping with the Change Management application to detect and manage unauthorized changes on configuration items (CIs) within application services. When an unauthorized change activity is detected, an emergency unauthorized change request is automatically created, enabling timely review and action to maintain control over the IT environment.

    Show full answer Show less

    Key Features

    • Automatic Detection and Notification: Unauthorized changes on CIs trigger a ci.change.unplanned event, which creates an emergency change request pre-filled with key details such as the affected CI, description of changes, and assignment to the Change Management group.
    • Flapper Algorithm: A machine learning-based algorithm identifies false positives caused by measurement errors or minor value differences (e.g., case sensitivity). It minimizes unnecessary emergency change requests by ignoring these flapper changes, improving accuracy and reducing noise.
    • Review and Approval Workflow: Change managers can review unauthorized change requests, approve or reject them, and assign post-implementation review tasks to evaluate risks and impacts.
    • Configurable Settings: Administrators can enable or disable unauthorized change detection, modify unauthorized change requests by clearing the "Unauthorized" checkbox (converting them to emergency changes), and manage notification preferences to avoid excessive emails when multiple changes occur.
    • Notification Controls: Email notifications are sent to relevant stakeholders for awareness and prompt action, with the option to disable notifications when needed to reduce alert fatigue.

    Practical Use for ServiceNow Customers

    By leveraging this capability, customers can:

    • Ensure immediate visibility and control over unplanned changes to critical CIs that could impact application services.
    • Reduce risks associated with unauthorized changes by enforcing an emergency change process and post-implementation reviews.
    • Minimize false alarms through intelligent filtering, which helps focus efforts on genuine unauthorized changes.
    • Customize the detection and notification settings to align with organizational policies and reduce unnecessary alerts.
    • Streamline incident and change management processes by integrating unauthorized change detection directly into the existing Change Management workflows.

    Next Steps

    • Review and configure the Unauthorized Change Properties to enable or tailor unauthorized change detection as per your environment.
    • Train change managers to review, approve, or reject unauthorized change requests, and to perform post-implementation reviews when changes occur without prior approval.
    • Consider notification settings to balance timely alerts with minimizing notification overload.
    • Utilize related change management tasks such as creating change requests from CIs, standard change requests, and outages to support your change governance processes.

    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.
    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.

    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 flag.

    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.
    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

    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.

    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.