How do you handle stale CIs for which Discovery does not set the "Most recent discovery"

[cloudyrobert]

I'm working through our rather sizable list of stale CIs by class. For classes, such as Disk Partitions, where the OOB probes/patterns do not set the "Most recent discovery" and "Discovery source" and the stale metric is being created based on the sys_updated_on field, how do you remediate? The sys_updated_on field isn't updated every time the CI is found, so we have valid CIs that have no changes, are therefore not updated, and show as stale. I wish the discovery fields were set for every discovered class, but since they are not, how do you handle this?

[cloudyrobert]

This makes sense, I guess my concern is that it will potentially leave partitions (in this specific scenario) that no longer exist associated with active CIs. Say a partition is deleted, but the CI is not retired. As far as I know, nothing is automatically done with that partition CI, so it persists in the related list for the hardware CI.

Thoughts?

[Patrick DeCarl1 · Accepted solution]

If you are using patterns, the OOTB deletion strategy would delete those records if they were removed from the device. 

https://docs.servicenow.com/bundle/london-it-operations-management/page/product/discovery/task/set-d...