ServiceNow Automated Change Reconciliation

Included in Version Release Date
V4.3.46.0

July 2024 Quarterly Release

The Automated Change Reconciliation functionality was developed as a way to streamline the workflow of your change management process between Cloudhouse Guardian (Guardian) and ServiceNow by automating arduous tasks. The change reconciliation automation allows you to track and manage node changes by providing detailed comparisons between pre and post-change states, improving policy compliance and reducing the effort required for manual validation. This topic describes how Guardian facilitates the management of change requests, ensuring efficient and accurate change reconciliation in your change management workflow.

Dependencies

To use the Automated Change Reconciliation functionality, an existing ServiceNow integration with Guardian is required. For more information, see ServiceNow Integration.

Overview

The Automated Change Reconciliation process takes place in Guardian and ServiceNow. The following items outline each stage of the process, from the change request creation to the validation results stage.

Automated Change Reconciliation Stages

The table below describes the seven stages of the Automated Change Reconciliation functionality between Guardian and ServiceNow.

Stage Description
1. Change request is created in ServiceNow. The change management process begins when a change request is created in ServiceNow. The request includes details about the proposed change, such as the reason for the change, the components involved, and the expected impact.
2. Guardian analyzes the change request.

When a change request is scheduled in your ServiceNow instance, Guardian analyzes the request's proposed change, scope, and potential impact on the nodes.

To allow Guardian to validate if a change request is in compliance with a policy after the implementation stage, the corresponding policy in Guardian must have the same name as the change request ID. For example, if the change request ID is 'CHG0012345', you need to have a policy with the name 'CHG0012345' so Guardian compares the change request to that specific policy and evaluates if the policy passes or fails after the implementation is complete.

Note: For more information on how to create or edit a policy, see Policies.

3. Impacted nodes are flagged in Guardian.

Once Guardian has analyzed each of the nodes in the Monitored tab (Inventory > Monitored), the node(s) that could be affected by the request are flagged (), providing clear visibility into possible upcoming changes in the Change Requests page. You can select a flagged node or node group to display the Change Requests page. The Change Requests page displays information about a selected node or node group's associated change request, providing clear visibility into possible upcoming changes. For more information, see View Change Requests.

Note: Guardian only considers nodes present in the Monitored tab. Nodes in other states are not considered. For more information, see Detected and Monitored Nodes.
4. Implementation stage begins in ServiceNow.

Once the impacted nodes are flagged, the change request in ServiceNow begins the implementation stage. This means the change has been analyzed and is ready to be executed.
5. Scan triggered in Guardian.

After the implementation stage is complete, Guardian triggers a scan of the impacted nodes to detect any changes that have been made. This post-implementation scan ensures that the changes were applied correctly and that there are no unintended modifications.
6. Post-implementation changes detected.

During the post-implementation scan, Guardian validates and lists all changes made during the implementation. Guardian checks if the changes comply with the established policy you set in 2. Guardian analyzes the change request.. If there isn't a policy that matches the impacted node(s), Guardian will only check for pre and post-implementation differences.

All validation checks analyzed by Guardian are listed in the change request in ServiceNow for review and remediation.
7. Validation results list created in ServiceNow.

A list of validation results are added to the change request in ServiceNow. Including all validation checks detected by Guardian when scanning nodes before and after the implementation stage. For example, 'Node x successfully validated (Change detected)'. For more information, see View Guardian Validation Results.

Note: You can see if a validation check has failed or succeeded in the Events tab (Control > Events). For more information on how this tab operates, see Events.

View Change Requests

The Change Requests page displays detailed information about each change request, including its ServiceNow ID, description, state, and more. By consolidating all relevant change request data in one place, you can easily track and manage change requests.

To view the change requests associated with a particular node, from the Monitored tab, click the flag icon () next to the node you want to see the change requests' details. The Change Requests page is displayed. For more information on what the Change Requests page displays, see the table below.

To view the change requests associated with a particular node group, from the Monitored tab, click Change Requests to see the change requests' details.

Note: If you want to display the list of monitored nodes contained within a different node group, select a node group from the Node Groups drop-down menu.

The Change Requests table displays information about each change request within the following columns:

Note: When viewing a node or node group's change requests, each row represents a change request associated with a different node.

Column Description
Change ID

The unique alphanumeric string that identifies a change request in ServiceNow. Change IDs usually follow a specific format, for example, 'CHG0001234'. If selected, you are taken to the change request in ServiceNow, where you can track and manage the change request's status, progress, and history.
Description A brief summary of what the change request entails.
State

The change request's current status. The following options can be displayed, depending on which stage the change request is in:

  • 'New' – Created but not yet reviewed or assigned.

  • 'Assess' – Being assessed to determine its impact, risk, and required resources.

  • 'Authorize' – Awaiting approval from the relevant stakeholders.

  • 'Scheduled' – Approved and scheduled for implementation.

  • 'Implement' – The planned start date has approached and the actual work is being implemented.

  • 'Review' – Work is complete and it is being reviewed for approval and any post-implementation issues.

  • 'Closed' – Work has been reviewed and completed. No further actions are required.

  • 'Canceled' – Canceled due to not being required. A change request can be canceled at any time, unless it's in the 'Closed' state.
Node Name The name of the node that the change request is associated with. If selected, you are taken to the node's latest scan results page.
Planned Start Date/Time The date and time the change request is scheduled to begin.
Actual End Date/Time

The date and time the change request was actually completed.

Note: This value is only displayed after the 'Implement' stage.

Once implementation work is completed, Guardian triggers a scan of the node(s) impacted by the change request to identify how the nodes have changed after implementation. Guardian then creates a list of all validation results in ServiceNow, where you can see detailed information on the outcomes detected. For more information, see below.

View Guardian Validation Results

When viewing a change request in ServiceNow, the Activity field is populated with the validation checks analyzed by Guardian after the implementation stage is complete. Guardian compares the pre-implementation state against the post-implementation state to identify the changes performed during the implementation and ensures that the changes meet the predefined policy set in your Guardian instance.

Warning: Guardian will only validate if a change request is in compliance with a policy, if the policy name in Guardian matches the corresponding change request ID. For more information, see 2. Guardian analyzes the change request.If there isn't a policy that matches the impacted node(s), Guardian will only check for pre and post-implementation differences.

The automatic validation minimizes the need for manual intervention and the effort involved in investigating and validating the changes performed.

The table below describes the validation messages that could be displayed in the Activity field in the change request in ServiceNow:

Note: In cases where a change is detected, Guardian automatically adds a link to the impacted node's scan results page where you can see the difference(s) detected and make comparisons between nodes, files, or scans. For more information, see Configuration Differencing.

Validation Message Description
Node x successfully validated using policy y.

Validation completed without failures.
Unable to locate node x in Guardian for validation. Guardian couldn't find the node in the Monitored tab.

Commencing validation for affected node x.

Node x failed validation due to not being scanned in the last 24 hours. Guardian event raised.

 Guardian couldn't find a successful node scan in the past 24 hours to compare with the post-implementation state.
No policy found for change. Validating via change detection only. Guardian couldn't find a policy that matched the change request. As a result, Guardian only compared differences between pre and post-implementation scans.

Node x successfully validated (Change detected).

Details: link to the scan results page in Guardian.

Validation completed without failures. Guardian detected a difference between pre and post-implementation scans.
Node x failed validation. No change detected. Guardian event raised. Guardian couldn't find any changes between pre and post-implementation scans. In this case, the change might not have occurred or the node scan settings ignored the change. For more information, see Node Scan Ignore Lists.

Using policy x for validation.

Unable to locate a node scan for node x with ServiceNow change request ID.

 Guardian couldn't find a node scan to check because the node scan wasn't tagged with the change request ID. In this case, you can either select the Scan CIs (nodes) on Work End checkbox while adding a ServiceNow Integration or manually tag a node scan. For more information, see Tagging.

Node x failed validation using policy y. Guardian event raised.

Guardian identified a policy failed hence the validation failed. You can see why a policy failed by looking at the node scan results page or the policy report. For more information, see Node Scan Results and Policies.

Guardian's validation checks that either fail or succeed are noted in the Events tab. Here, you can add a ServiceNow action to create a ServiceNow record every time a 'Change Validation' event occurs. For more information on how to achieve that, see Action: Create a Record in ServiceNow.