--- sourceDocument: Australia Security Management sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/security-management Release : - australia ft:locale : - en-US ft:publication_title : - Australia Security Management ft:clusterId : - security bundleId : - security workflow : - Technology --- # State synchronization between change requests and remediation tasks # State synchronization between change requests and remediation tasks {#ariaid-title1} * Release version: Australia * * Updated March 12, 2026 * * ![](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 State Synchronization Between Change Requests and Remediation Tasks The Vulnerability Response product in ServiceNow features a synchronized relationship between the State fields of change requests (CHG) and remediation tasks (VUL). When a change request progresses through its lifecycle, it automatically updates the state of any associated remediation tasks, ensuring seamless management of vulnerabilities. Show full answer Show less ## Key Features * **Automatic State Updates:** When a new CHG is created or associated with a VUL, the VUL state advances to Awaiting Implementation unless it is already in that state. * **Forward Synchronization:** CHGs in completed states (Review or Closed) trigger the VUL to move to Resolved. * **Backward Synchronization:** If a CHG is cancelled or closed unsuccessfully, the VUL reverts to Under Investigation. * **Multiple CHGs Management:** The state of a VUL with multiple associated CHGs is determined by the earliest state of those CHGs, ensuring the VUL reflects the most critical task's status. ## Key Outcomes By enabling state synchronization through the system property (snvul.crstatesynch), users can expect: * Streamlined tracking of remediation efforts in relation to change requests. * Minimized manual updates, as the system automatically adjusts states based on CHG progress. * Increased clarity and control over the remediation lifecycle, allowing for better management of vulnerabilities. There is a synchronized relationship between the State fields of remediation tasks (VULs) and the State fields of change requests (CHG) in the Vulnerability Response product. As a change request moves through its life cycle, it also moves the state of any related remediation tasks automatically. ## State synchronization {#vuln_change_mgmnt_state_synch__section_zqs_ydr_cjb} The remediation task record is referred to as a VUL in the following sections. In previous versions of Vulnerability Response, remediation tasks were called, vulnerability groups (VG). In the following images, VG= remediation task, or a VUL record. State synchronization is enabled by a system property (sn_vul.cr_state_synch) by default in your instance when you download the Vulnerability Response application. When state synchronization is enabled, the CHG State field changes the remediation task State field automatically in the following cases: * When a new CHG is created for a remediation task (VUL), if it is not in Awaiting Implementation, the VUL state moves forward to Awaiting Implementation. * When an existing CHG is associated to a VUL, if it is not in Awaiting Implementation, the VUL state moves forward to Awaiting Implementation. * After the tasks on a CHG are completed (Implemented), and the CHG is moved to the Review state, the VUL moves forward to Resolved. {#vuln_change_mgmnt_state_synch__ul_dv1_jhz_cjb} For more information and examples of state synchronization, see the following sections. Note: You can still manually move CHGs and VULs through the states of their life cycles on their respective records with state synchronization enabled, but when the system registers that a CHG has changed its state, or you add a CHG or remove it from a VUL, state synchronization potentially can override your manual intervention. However, change requests states do not automatically move the VUL from the Closed or Deferred states. ## Forward state synchronization {#vuln_change_mgmnt_state_synch__section_arr_mmz_cjb} The following image illustrates how CHG states automatically move VUL states in a forward life cycle, that is, from Open to Resolved. You can create new change requests for any remediation task in a state other than Closed. State synchronization automatically moves the VUL 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 VUL 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 VUL, because investigations or tasks on the CHG are not completed. State synchronization is invoked when a CHG is created for, or associated to, the VUL, or 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 VUL moves forward to Resolved. ## Backward state synchronization {#vuln_change_mgmnt_state_synch__section_rpg_qmz_cjb} As a CHG is processed during its life cycle, it may be canceled at some point. In this case, if the CHG is Cancelled, or Closed (with a close code of Unsuccessful), the VUL automatically moves back to Under Investigation. The VUL moves back to Under Investigation, because there is no active plan to remediate the vulnerability. If a VUL 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 VUL automatically transitions back to Awaiting Implementation​. The VUL moves back to this state, because more work is now assigned to the CHG. ## VULs with more than one CHG {#vuln_change_mgmnt_state_synch__section_hjs_5mz_cjb} If a VUL 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, a VUL has four CHGs associated with it, CHG1, CHG2, CHG3, and CHG4 as shown in the following table. {#vuln_change_mgmnt_state_synch__table_p5t_g4z_cjb__entry__2} | CHG number | CHG state | |-|-| | 1 | Implement | | 2 | Canceled | | 3 | Closed (close code of Unsuccessful) | | 4 | Closed (close code Successful) | [ ] {#vuln_change_mgmnt_state_synch__table_p5t_g4z_cjb} State synchronization between the CHG and the VUL in this case is based on CHG1, which is in the earliest state of the four CHGs, (Implement). In this case, the VUL remains in Awaiting Implementation. In another example, if a VUL 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 VUL 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. {#vuln_change_mgmnt_state_synch__table_pzz_5y4_gjb__entry__2} | CHG number | CHG state | |-|-| | 1 | Review | | 2 | New | [ ] {#vuln_change_mgmnt_state_synch__table_pzz_5y4_gjb} Additionally, when VULs have more than one CHG, the state of the VUL transitions automatically in the following cases: * When a CHG moves forward to Review, if all other CHGs associated with the VUL are in Review or Closed states (with a successful close code), the VUL automatically transitions to Resolved. Any other related CHGs that are canceled or closed unsuccessfully are ignored. * When a CHG moves to Cancelled or Closed (close code of Unsuccessful), if all other CHGs associated with the VUL are in the same state, then the VUL automatically transitions back to Under Investigation. {#vuln_change_mgmnt_state_synch__ul_sjb_dkg_djb} For more information about remediation task states and what you can do in each state, see [Vulnerability Response remediation task and vulnerable item states](https://servicenow-prod.fluidtopics.net/WxaJrhnoLTHqOnIz9WpoLA "With the Vulnerability Response application, you can use the state model to see the status of a remediation task, at any given time. Knowing how each state relates to and affects each other helps you to determine when and how to remediate your vulnerable items (VIs).").