Stale CIs when discovery is not used

[Nithin21]

As per docs, Stale CIs is calculated based on the field Most recent discovery

OOB, if most recent discovery is more than 60 days, CI is classified as Stale in CMDB Health dashboard.

What is the case when discovery is not used ?

How can we manage CIs as field Most recent discovery is empty.

Is it not recommended to retain Stale CIs as a KPI in the absence of Discovery

[Nithin21]

Any thoughts from experts?

[christianmalone]

There is also a cmdb health property for staleness value which is calculated from CI update date. Using this it will mark CI records as stale if no updates have occurred - allowing for manual CI’s to still be accounted for in the staleness reporting. Set this property value then enable GRC and create a data certification audit to ask CI owners to certify their records periodically. Update a field in the CI record from this process and if they skip it then it should show up in your staleness health audit. Even better use Discovery to automate many of the CI fields so you don’t rely solely on manual entry.

[Nithin21]

Would it be possible to share steps on how to do the below config ?

Set value for "cmdb health property for staleness value which is calculated from CI update date"

Enable GRC

Create a data certification audit

[cycomer]

The CMDB Health Dashboard isn't going to be very useful if you aren't using the Identification and Reconciliation API. You probably have some data sources updating Hardware/Infrastructure CIs right? Those data sources could be retrofit to use ID/Recon but that's a big project. Secondarily you could have your datasources update Most Recent Discovery just by adding that field map. If you don't have other data sources and everything in the CMDB is manually updated then this metric is meaningless.