CMDB CI Staleness rules and reporting on old Incidents/TASKS

[OGF]

Hello, this question is about CMDB Staleness rules and how they impact reporting on existing old and closed INC, REQ, CHG, PRB, TASK records. Does anyone have insight as to how the following scenarios are usually tackled in the system/what have you seen in the past? I appreciate any insight. Thanks a bunch.

Short summary about Staleness Rules in CMDB

1. Staleness occurs when a CI has not been updated in the CMDB for a specified period. This can happen if the CI is no longer detectable on the network and cannot be scanned by a discovery tool, or if the discovery process has changed and the CI is no longer included in the scope for automatic scanning. Since infrastructure and applications frequently change, having stale CIs can adversely affect the overall health of the CMDB.
2. Base System Staleness Rule exists and only one staleness rule is defined at the base CI class level, Configuration Item [cmdb_ci], and it applies to all extended child classes in the CMDB. This rule indicates that a CI is considered stale if it has not been updated for 60 days.
3. Usually, to fix stale CIs you either maintain it with a CMDB manager who sees those stale CIs on the health dashboard and fixes them or you use remediation rules. Assign a remediation task to the CI owner or group.

Business Scenario:

1. CI exists in CMDB and is operational, then
2. an Incident is opened for this CI, then 
3. an Incident is resolved and closed
4. This CI is not updated by Discovery/Integration/CMDB manager for 90 days and is deemed stale
5. When a CI is deemed stale, then:
   1. system automatically sets CI as retired OR sets CI to non operational OR archives the CI (no decision made on this yet, and these are the options that are being considered)

Questions on this scenario

1. If CI is set to retired;
   1. and a report is run to review against which CIs incidents have been created in the last 6 months, will the CI name still show on the report OOTB?
2. If CI is set to non operational;
   1. and a report is run to review against which CIs incidents have been created in the last 6 months, will the CI name still show on the report OOTB?
3. If CI is archived;
   1. and a report is run to review against which CIs incidents have been created in the past 6 months, will the CI name still show on the report OOTB?

[Abbas_5 · Accepted solution]

Hello @OGF,

When a CI is deemed stale and set to "retired" or "non-operational", the CI name might still appear on reports, depending on the report's filter and the reporting engine's behavior. If the report specifically excludes "retired" or "non-operational" CIs, they won't be included. Otherwise, they might still show, but with a status indicating they are not operational. 

Scenario: CI set to Retired 

• Report OOTB:

  If the report's filter is based solely on CI status, a "retired" CI might still appear on reports that include all CIs, including those with a "retired" status. The report might show the CI name, but with a status indication that it is retired.
• OOTB Report Filters:

  The report's OOTB filter might have a field that excludes "retired" CIs, preventing them from showing up. However, it's important to test this with your instance.
• Custom Report Filters:

  If you've customized the report, you can use the CI status field to filter out retired CIs. 

Scenario: CI set to Non-Operational 

• Report OOTB: Similar to the "retired" scenario, a "non-operational" CI might appear on reports that don't filter out this status.
• OOTB Report Filters: The report might include a filter that excludes "non-operational" CIs.
• Custom Report Filters: You can use the CI status field to control the visibility of "non-operational" CIs. 

Key Considerations:

• CI Status Field:

  The CI status field is a key element in determining which CIs appear on reports.
• Report Design:

  Review the report design to see if it explicitly filters based on CI status.
• CMDB Configuration:

  The CMDB staleness rules and how they impact CI status are crucial.
• Testing:

  Always test your reporting scenarios in your instance to verify the behavior of reports and filters. 

Best Practices:

• Data Governance: Implement strong data governance practices to ensure accurate CMDB data.
• Staleness Remediation: Automate stale CI remediation using ServiceNow's remediation rules or other CMDB management tools.
• Regular Audits: Perform regular CMDB audits to identify and address stale or inactive CIs.
• Documentation: Document your CMDB rules and reporting procedures. 

By carefully configuring staleness rules, defining clear remediation processes, and verifying your reports, you can ensure that your CMDB data remains accurate and that your reports provide a reliable view of your IT environment. 

If this is helpful, please hit the thumbs up button and accept the correct solution by referring to this solution in future it will be helpful to them.

Thanks & Regards,

Abbas Shaik

[OGF]

Thanks very much!