State synchronization between change requests and remediation tasks

  • Release version: Zurich
  • Updated July 31, 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 State synchronization between change requests and remediation tasks

    This feature in the Configuration Compliance application synchronizes theStatefields between change requests (CHGs) and remediation tasks, ensuring that the status of remediation efforts aligns with associated change activities. This synchronization is controlled by the system propertysnvulc.crstatesync, which is enabled by default starting with version 12.0 of the Configuration Compliance application.

    Show full answer Show less

    As change requests progress through their lifecycle, the remediation tasks linked to them automatically update their states accordingly, maintaining consistency and reflecting the current remediation status.

    Key Features

    • Automatic Forward State Synchronization: When a new or existing change request is associated with a remediation task and is beyond the Awaiting Implementation state, the remediation task state advances automatically to Awaiting Implementation.
    • Once all tasks on a change request are completed (Implemented), and the change request moves to Review, the remediation task state moves forward to Resolved.
    • The system supports manual state changes on both remediation tasks and change requests; however, state synchronization may override manual changes when it detects state changes on the change request or modifications in their association.
    • Backward State Synchronization: If a change request is Canceled or Closed with an unsuccessful close code, the remediation task automatically reverts to Under Investigation, indicating the remediation plan is inactive.
    • If a remediation task is Resolved but a new or existing change request in an early open state is associated, the remediation task transitions back to Awaiting Implementation.
    • Handling Multiple Change Requests: When multiple change requests are linked to a remediation task, synchronization is governed by the CHG in the earliest state within its lifecycle.
    • The remediation task moves to Resolved only when all associated change requests are in Review or successfully closed states.
    • When all associated change requests are canceled or unsuccessfully closed, the remediation task transitions back to Under Investigation.
    • State synchronization is automatically invoked when change requests are created, associated, or their state changes unless the user explicitly disables it via the Add CIs to CR checkbox.
    • Terminology updates as of v14.9 renamed "Test Result Group" to "Remediation Task Group," "Rules" to "Remediation Task Rules," and "Policy Test group" to "Change Request."

    What This Enables for ServiceNow Customers

    This synchronization streamlines vulnerability remediation by ensuring remediation tasks accurately reflect the status of their related change requests, reducing manual tracking and potential errors. Customers can rely on the system to keep remediation progress aligned with change management activities, improving operational efficiency and visibility into compliance remediation workflows.

    With this feature, customers can expect:

    • Consistent and automated state updates between remediation tasks and change requests.
    • Clear visibility into remediation status based on change request progress.
    • Automatic rollback of remediation states if remediation activities are canceled or unsuccessful.
    • Support for complex scenarios involving multiple change requests per remediation task.
    • The flexibility to manually override states if needed, with awareness that synchronization may subsequently adjust states.

    There is a synchronized relationship between the State fields of remediation tasks and the State fields of change requests (CHGs) in the Configuration Compliance application.

    Note:
    Starting with v14.9 of Configuration Compliance, the following terms have been renamed:
    Table 1. Changes in terminology
    Terminology prior to v14.9 Terminology v14.9 onwards
    Test Result Group Remediation Task
    Group Rules Remediation Task Rules
    Policy Test group

    As a change request moves through its life cycle, it also moves the state of any related remediation tasks automatically. State synchronization is enabled by a system property (sn_vulc.cr_state_sync) by default in your instance when you download the Configuration Compliance application from the ServiceNow Store starting with v12.0.

    When state synchronization is enabled, the CHG State field changes the remediation task State field automatically in the following cases:

    • When a new change request is created for a remediation task, if it is not in Awaiting Implementation, the remediation task state moves forward to Awaiting Implementation.
    • When an existing change request is associated to a remediation task, if it is not in Awaiting Implementation, the remediation task state moves forward to Awaiting Implementation.
    • After the tasks on a change request are completed (Implemented), and the CHG is moved to the Review state, the remediation task moves forward to Resolved.

    For more information and examples of state synchronization, see the following sections.

    Note:
    You can still manually move change requests and remediation tasks through the states of their life cycles on their respective records with state synchronization enabled, but when the system registers that a change request has changed its state, or you add a change request or remove it from a remediation task, state synchronization potentially can override your manual intervention. However, change request states do not automatically move the remediation task from the Closed.

    Forward state synchronization

    The following image illustrates how CHG states automatically move remediation task states in a forward life cycle, that is, from Open to Resolved.

    How CR states drive CTR states.

    You can create new change requests for any remediation task in a state other than Resolved or Closed. State synchronization automatically moves the TRG bi-directionally through the Open, Under Investigation, Awaiting Implementation, and Resolved states. This movement is based on certain values of the state field on the change request. State synchronization between the change request and the remediation task is invoked automatically unless the check box (Add CIs to CR) is displayed on a form and you choose to clear the check box.

    The remediation task does not move forward to Resolved when a CHG is in its open states. Any CHG in states prior to Review in its life cycle such as, New, Assess, Authorize, Scheduled or Implement, as shown in the preceding figure, are considered open states for the CHG. Open states do not move the state field on the remediation task, because investigations or tasks on the CHG are not completed. State synchronization is invoked when a CHG is created for, or associated to, the remediation task, or when the state of an existing relationship changes on the CHG. The completed CHG states are Review and successfully Closed. When a CHG is closed successfully, its closed codes are: Successful, or Successful with issues, in which case the remediation task moves forward to Resolved.

    Backward state synchronization

    As a CHG is processed during its life cycle, it may be canceled at some point. In this case, if the CHG is Canceled, or Closed (with a close code of Unsuccessful), the remediation task automatically moves back to Under Investigation. The remediation task moves back to Under Investigation, because there is no active plan to remediate the vulnerability.

    If a remediation task is in a Resolved state​, and you create a new CHG or associate it to an existing CHG in one of the initial open states​, the remediation task automatically transitions back to Awaiting Implementation​. The remediation task moves back to this state, because more work is now assigned to the CHG.

    Remediation tasks with more than one CHG

    If a remediation task in Awaiting Implementation has more than one CHG associated with it, state synchronization is based on the status of the CHG in the earliest state of its life cycle. For example, say a remediation task has four CHGs associated with it, CHG1, CHG2, CHG3, and CHG4 as shown in the following table.
    CHG number CHG state
    1 Implement
    2 Canceled
    3 Closed (close code of Unsuccessful)
    4 Closed (close code Unsuccessful)

    State synchronization between the CHG and the remediation task in this case is based on CHG1, which is in the earliest state of the four CHGs, (Implement). In this case, the remediation task remains in Awaiting Implementation.

    In another example, if a remediation task is in the Resolved state and has an existing CHG that has been implemented and is in the Review state, and a new CHG is created, the remediation task moves back from Resolved to Awaiting Implementation. State synchronization is based on the CHG in the New state, which is the CHG in the earliest state.

    CHG number CHG state
    1 Review
    2 New

    Also, when remediation tasks have more than one CHG, the state of the remediation task transitions automatically in the following cases:

    • When a CHG moves forward to Review, if all other CHGs associated with the remediation task are in Review or Closed states (with a successful close code), ​the remediation task automatically transitions to Resolved​. Any other related CHGs that are canceled or closed unsuccessfully are ignored.
    • When a CHG moves to Canceled or ​Closed (close code of Unsuccessful), if all other CHGs associated with the remediation task are in the same state, then the remediation task automatically transitions back to Under Investigation​.

    For more information about remediation task states and what you can do in each state, see Configuration Compliance states.