CMDB Data Manager vs CMDB Health Correctness Staleness, how to combine?

[Arby]

With the arrival of CMDB Data Manager, it seems like there is an overlap in functionality when it comes to retirement of stale CI's. Staleness tasks and their related workflows can be implemented via CMDB Health Metrics or via CMDB Data Manager.

What is good practise when it comes to handling stale CI retirement?
- let retirement be handled via Health and use archival and deletion policies in data manager to keep the CMDB lean in the long run?
- disable health staleness rules and implement retirements policies in data manager??
- other options?

[CMDB Whisperer · Accepted solution]

Asset retirement, in general, should be an intentional transaction rather than an automated state change.  There are many reasons why a CI can become stale.  Some of these may have more to do with systems  than the device itself (e.g. inability to discover the device, duplication at the CI level, etc.).  So I would say that the best way to use CMDB Data Manager is in conjunction with Staleness rules in the CMDB.  Reporting on Staleness rules and even creating and assigning Follow-on tasks to investigate Stale CIs allows asset managers to have a chance to confirm the status of an asset that is expected to be active but is not, and it also allows CMDB and Discovery administrators the opportunity to identify and address system issues or duplication that may be the underlying cause of the staleness.  So using CMDB Data Manager to allow for a period of time for staleness to be investigated first is ultimately better all around.  That said, it is important to implement and execute the verification and audit processes that allow this investigation to happen.