Active CIs Updated in Last 90 days Get Well Playbook Refresh Stale CIs in your CMDB A guide for how to refresh stale CIs Table of Contents Summary. 3 Audience. 3 Problem Overview.. 3 Executive Summary. 4 How this playbook can help you achieve your business goals 4 How this playbook is structured. 4 Problem Analysis 4 Upstream Causes 4 Downstream Consequences 5 Impact on Your Business 5 Engagement Questions 6 Remediation Plays 6 Summary. 6 Analysis Play. 6 Fix Play. 8 Data Governance Play. 10 Summary Goal of this Playbook The goal of this playbook is to help you identify and refresh the stale configuration items (CIs) in the Configuration Management Database (CMDB). Author Emir Eminovic, Callan BondDate 05/01/2025Addresses HSD # HSD0002998, HSD0003550Applicable ServiceNow Releases All ReleasesTime required Approximately 1-4 Hours Audience Configuration Managers or Configuration Management teamServiceNow Administrators Note: As you follow the instructions in this playbook, you may need help from people in the following roles: Discovery AdministratorAsset ManagerThird-party Application Owner Problem Overview A stale configuration item (CI) is one that you have not updated within a specific number of days (for example, 90 days). Stale CIs can lead to: Incorrect decisions where the data is used (for example, at the Application Level). Inaccurate classification of risk and level of urgency, which can increase the mean-time-to-respond (MTTR).Erosion of trust in the CMDB. Stale CIs being marked as non-operational, which can negatively affect system performance.Inaccurate lifecycle states, which can create a poor user experience. Executive Summary How this playbook can help you achieve your business goals Incident Reduction Data Accuracy Process Automation Data Accuracy Audit/Compliance System Integrity Lower MTTR Data Validation How this playbook is structured This playbook guides you through three plays. The first play (an analysis play) lets you see the number of stale CIs in your CMDB, if any. The second play (a fix play) lists the methods you can use to refresh the stale CIs, and helps you choose one or more of those methods. The third play (a governance play) explains the processes you can use to prevent creating stale CIs. Problem Analysis Upstream Causes The following can create stale CIs: Data population has not been scheduled or has not been done in the last 90 days. Issues with Discovery, such as: Discovery has not been scheduledDiscovery does not complete due to errors, such as an expired credentialDiscovery coverage is insufficient Custom CI Import jobs or integrations are not working, or the refresh period has been changed to more than 90 days. Decommissioning processes are set up incorrectly or Lifecycle states are not updated.Legacy data or manual entries are not connected to any automated discovery process.Previously imported legacy data has not been refreshed. Downstream Consequences Data Consequence Data is out-of-dateCI state is out-of-date date Relationships to other CIs and services are out-of-date Ownership Information is out-of- date Data is overloaded (bloated) Operation Consequence If you cannot trust the data in the CMDB, you may decide to create a source that you can trust. For example, you might create an additional report or vendor console. Having two data sources can lead to additional overhead activities and integration problems. Stale CI data can cause service outages or configuration errors. Application Consequence The stale CIs cause lower CMDH Health Dashboard Correctness scores.Applications that use the stale CIs in the CMDB, such as IT Service Management (ITSM) and IT Operations Management (ITOM), show inaccurate data. This inaccurate data can lead to incorrect decisions. Example: Asset Management: Reporting incorrect Service Pack and Security RiskReports containing stale CI information are inaccurate, require additional validations, and raise questions. Impact on Your Business Stale CIs can cause you to make incorrect decisions about data at the application level. Stale CIs can also adversely affect your high-priority business initiatives. Engagement Questions Consider the answers to these questions: Do you have automated Discovery, Service Mapping, or Import schedules? How often do run your schedules? Do you see any errors? What is the most reliable source for your CI data and specific classes? What CIs do you enter manually? Do you periodically re-certify your data (for all or some of classes)? Do you have defined CI Lifecycle states? Are you using the lifecycle state definitions included with the base system? If not, what definition states are you using? Remediation Plays Summary The table below lists and summarizes each of the remediation plays in the playbook. Details are included later. Play Name Analysis What this play is about Lets you see if you have any stale CIs in the CMDB. Required tasks If you have stale CIs, run a script to get details. Fix What this play is about Lists the methods you can use to refresh the stale CIs. Methods vary according to the root cause. Required tasks Use one or more of the available methods to refresh the stale CIs. Data Governance What this play is about Lists the methods you can use to limit the number of stale CIs. Required tasks Use one or more of the methods to limit the number of stale CIs, and ensure data accuracy. Analysis Play What this play is about This play helps you identify stale CIs in your CMDB. To first find your stale CI’s CMDB health score and a list of details, use the CMDB and CSDM Data Foundations Dashboards. Required tasks Step 1: If you are on Xanadu family release or higher, the CMDB and CSDM Data Foundations Dashboards are available out of box. If you are on a version previous to Xanadu, navigate to the ServiceNow Store, search for “CMDB Data Foundations”, and install the free Store app. View the ServiceNow docs site to learn more about installing and configuring the Dashboards if you are setting them up for the first time. Step 2: Navigate to the CMDB Data Foundation Dashboard Step 3: Navigate to the “Data Management Practices” tab and review the “Active Cis updated in Last 90 days” metric. This metric looks only at Operational records in the Hardware and VM instance classes. If your score shows 100%, there are no stale Cis in those classes and so no further action is required. However, this metric should be reviewed monthly. Step 4: Click on the historical graph widget below to review individual records. First you must disable “Real time score” (small clock icon beside the date) and then enable “Show Records”. Doing this will display individual records that have not been updated in 90 days or more. You may group by Class or Location to do further analysis to determine the cause of the Stale records. In general, there are one of two reasons a CI record shows as stale: The equipment is still actively in use and on the network, but it is not getting picked up by Discovery or another tool or data load, and thus is showing as stale in the CMDB. If the CI were being properly discovered, it would be showing as Operational with a recent Updated date (Fix Plays A – D below). OR The equipment is no longer on the network, and the stale record should be retired and/or archived from the CMDB (Fix Play E below). Alternatively, and typically for a smaller percentage of potential stale records, the equipment may also be in maintenance and off network while the Operational status has not been updated properly to account for this change. Your analysis by Class and Location above can provide some hints as to the root cause. For example, if an inordinate number of stale records are all at a single location, it may be that the Discovery schedule running at that location has an issue and should be investigated. You may also notice a large number of records associated to a CI class that is no longer in use at your organization or using an outdated naming structure, and so realize they are likely remnants from a previous data load and should be Retired and Archived. Fix Play What this play is about This play lists the methods you can use to refresh the stale CIs. Choose one of five methods (described below), based on the output of your analysis using the CMDB Data Foundations Dashboard “Active CIs Not Updated in 90 Days” metric. Review the detailed records associated with the historical graph widget for the “Active CIs Not Updated in 90 Days”. Important: Careful review helps you identify the root causes, which then helps you decide which refresh method to use. If you have more than one root cause, you need to address all of them. Refresh the category with the largest number of stale CIs first, or refresh the stale CIs in your most important CI classes. Choose the method you want to use, based on the root cause. The table below lists the root cause and the corresponding method to choose. What is causing the stale CIs (root cause) Method to use Discovery Method A Third-party applications Method B Data Imports Method C Manually entered CI records Method D Legacy CI records Method E Method A: Root cause — Discovery does not refresh the CIs Work with your Discovery Administrator to refresh this data and fix the root cause. Examine one CI class at a time. Verify that the Discovery schedules are active and are completing successfully. Check for any Discovery errors, such as problems with credentials, or firewalls. If you are using custom patterns, see if they are set to update the Last Updated timestamp. (Optional) Consider using a business rule that retires CIs that are not discovered. Review the IP exclusion ranges. Note: If the CI is no longer in the system, consider the answers to these questions: Is your asset-decommissioning process updating the CMDB when appropriate? Have you set up a deletion strategy for the related CI classes? Method B: Root cause — Third party applications are not refreshing the CIs Contact the third-party application owner and review how the data is sent to the CMDB. Ask the following questions: How are they managing the lifecycle of a CI and how are those updates sent to ServiceNow? Are only the deltas sent over periodically? Was the data sent as a one-time only activity? Can it be set up to happen more frequently? Can a "refresh" job be performed? Check if the third-party application supports passing the data though the Identification and Reconciliation Engine (IRE). (Optional) Consider using Discovery as a validation mechanism for your CIs. Method C: Root cause — ImportSets are not updating the CIs CIs that have been manually imported but are now stale may fall into one of two categories. The first is that the CIs may be hardware that really should be discovered automatically. If this is the case, consider identifying if Discovery or another discovery tool that is already in use at your company can instead be used to discover the CIs. This is ideal as state of CIs may change, and automated tools often are able to discover more attributes than whatever was in a manually populated data set. The second is that the CIs may be legacy hardware that cannot easily be discovered. For example, some customers have a handful of mainframe computers that are still operational and need to be tracked in the CMDB. In the out of the box Data Foundations Dashboards all hardware CIs are included in the score calculation, so the stale legacy CIs will be included. These typically make up a small portion of an organization’s overall hardware footprint. You may however consider excluding these classes from detailed analysis described earlier in this playbook. When setting up Data Manager policies for retiring CIs, specific classes can be excluded. In this case those legacy classes (e.g., mainframes), should be excluded from Retirement policies. More information on using Data Manager is in the Data Governance Play section of this KB. Method D: Root cause — Manually entered CIs are not being updated Confirm that the CI has not been updated recently. If you know who manually entered the CI, find out why. See if there's a way to automate adding the CIs, or see if there's a way to certify periodically any records entered manually. Method E: Root cause — Stale CIs are remnants of the legacy CMDB records Are the legacy records still valid? Use Data Manager to mark them as retired or non-operational, and/or consider archiving them. For information on archiving the records, see the Governance Play. Data Governance Play What this play is about To help maintain freshness of data in your CMDB, you should use Data Manager to create Retire and Archive policies. Required tasks Use Data Manager to create Retire and Archive policies Data Manager is the tool to create and manage your Retirement and Archival policies of your CMDB Data. You can create policies that will run nightly that help maintain the hygiene of your CMDB. Step 1: Navigate to Data Manager, either from CMDB Workspace or directly from the left navigation bar. Step 2: Review Retirement Definitions and adjust as needed. Review the default Retirement Definitions within Data Manager. Retirement Definitions serve two purposes. First, they allow you to specify what lifecycle fields on a CI are set, and to what values, when Data Manager policies ‘retire’ a CI. Second, the definitions are used when an Archive policy is looking for ‘retired’ records. It will select all records that match the active Retirement Definitions. Update your Retirement Definitions as needed for your environment and lifecycle management processes. Note that out of box only the root cmdb_ci Retirement Definition is ‘Active’. All other Definitions are inactive unless set otherwise. In the out of box example above, when a Retirement Policy is triggered on a CI, it will set the Life Cycle Stage to End of Life and the Life Cycle Stage Status to Retired, in accordance with the Retirement Definition above. In addition, when an Archive Policy is run, it will Archive any CIs that meet the Retirement Definition (Life Cycle Stage is End of Life and Life Cycle Stage Status is Retired). A Retirement Definition at a more granular level overrides any retirement definitions higher up in the hierarchy. Step 3: Create your Retirement Policy A Retirement policy will Retire (set fields identified by your Retirement Definitions) CIs that match the filter criteria you set in the policy. Typically, you should retire CIs that have not had been updated (Updated / sys_updated_on field) for more than 60 days, and that are currently in an operational state. Refer to ServiceNow docs for full details on creating a Retirement policy. In general you will: From Data Manager, select Policies and then Create New Policy Fill out the general information for the policy and select type Retire Set the policy filter to identify the criteria for CIs to retire. Two key fields to set are: “Updated” which should be greater than 60 or 90 days depending on your discovery cycle. If your hardware and CM instance CIs are discovered on a daily basis, then 60 days is more than enough time. If a hardware or VM instance has not been seen for 60 days, it should be Retired. Life cycle fields. You should only look to Retire ‘Operational’ records. For example, the CI is “In maintenance” we do not want to set to Retired even if it has not been discovered for more than 60 days. “Operational status” is a common (legacy) field that is used, so you would set a filter condition to check if this status is Operational. Alternatively if you are using Life Cycle Stage and Lifecycle Stage Status, set the filter to check these fields. A sample policy: Select which User or Group (either specifically named, or a field associated to the CI such as “Managed By Group”) should get assigned. Note: in the next step you denote whether the CIs need Approval before being retired. If you will not require approval, it does not matter what you set in this step. Choose the subflow (there should be only one choice: Retire Configuration Items), and whether Approval is required. Note: CIs to be retired are grouped into Tasks. Each task may have up to 10,000 records, and each task will also group CIs together with one approver. So if you had 50,000 CIs that all had the same Approver, that Approver would receive 5 tasks. Click through the final Scheduling notification and Review. Finally if things look good, Publish the policy. Data Manager will display how many records will be affected by the conditions set in your Retirement policy. Start small and for your first policy, adjust the filter so that only a few hundred records are affected. After the policy runs (default is nightly), review the retired records and ensure the results are as expected. Step 4: Create your Archive Policy Once records are Retired, they can be Archived. Follow steps similar to the creation of a Retirement policy, however fewer filter conditions are usually needed as an Archive Policy can simply archive whatever records have been set to Retired. As with Retirement policies, you can set whether manual approval is needed prior to Archiving records. In addition, you can specify in Data Manager how long Archived records are retained prior to being deleted permanently from the CMDB. This value should be set in accordance with your organization’s record retention policy for the type of data that is being archived. Ensure you consult with appropriate data stewards within your organization before setting retention periods for Archived records. Once data is purged from Archived tables it cannot be recovered. Congratulations You have completed this Get Well Playbook.