Hello @nthelapolu,
The concept is right, but two pieces of the setup are worth double-checking before you trust the count: where the Class hierarchy gets applied, and which field you're using to measure "not discovered."
On the Retirement Definition side: this should live on the class where you want the lifecycle rule to apply, and per how Data Manager resolves definitions, a definition built on a parent class (Computer) is automatically inherited by every child class under it, laptops, servers, workstations, unless a specific child class has its own definition, in which case that one wins for that class only. So if all your Computer children should retire the same way (say, Operational status set to Non-Operational and Install status to Retired), one definition on cmdb_ci_computer is enough, you don't need one per child class. Just make sure it's marked Active, an inactive definition gets silently skipped by the policy at run time.
On the Retire Policy side, a few things to check:
- Data Filter table: point it at Computer [cmdb_ci_computer] directly rather than Configuration Item [cmdb_ci] with a class condition. Because child tables extend the parent table in this platform, a query against cmdb_ci_computer already pulls in every extended child class row, no "is a" condition needed. If you did build it off cmdb_ci with a class condition instead, that condition has to be Class is a Computer, not Class is Computer, same distinction that was causing your count mismatch earlier.
- Discovery staleness condition: use Most recent discovery (last_discovered) is before 3 months ago rather than a hard-coded date, so the threshold stays relative as time passes. Be aware this field is empty on CIs that were manually created or only ever loaded through an import, so an empty value will also satisfy "before 3 months ago" and those CIs get swept into the policy even though they were never actually discovered. If that's not the intent, add Most recent discovery is not empty, or scope by Discovery source, to the filter.
- Preview before activating: open the same conditions as a plain list view on cmdb_ci_computer and confirm the Included Records count in the policy preview lines up with it. That's the fastest way to catch a filter mismatch before it retires the wrong CIs.
One more thing worth confirming: if any Computer child class, say a specific hardware type, needs a different retirement definition than the parent, double check the policy's target table matches that child class specifically. Otherwise it inherits the parent Computer definition instead of the one you built for it.
Thank you,
Vikram Karety
Octigo Solutions INC
My Blog: glideandgen.com
