question Re: Life Cycle Stage and Status vs Operational Status & Install Status in CMDB forum

Life Cycle Stage and Status vs Operational Status & Install Status

agamage — Mon, 04 Mar 2024 00:45:43 GMT

We are using Life Cycle stages and utilizing CMDB Data Manager to retire CIs which haven't discovered for sometime.

If we consider Server Class as an example, please see OOB life cycle mappings:

When retiring the Server CI via data policy it's changing Operational Status and Install status as well. Which is great. Now if that retired server re-discovered via SN native discovery; CI will change only it's "Install Status" to 'Installed' and due to the configured LC mapping pirority order, this will not change the LC stage/status. We need these server CI's LC stage/status changed according to the discovery events as well.

We've allowed Operational Status within the system multiple places such as reference qualifiers, scripts etc.. So we'd like to keep utilizing this field as well.

What would be the best approach to achieve this?

Have same LC mapping pirority for "Install Status" field and "Operational Status" field.
- However if we've mapped same LC control to these two field values; LC stage will changed once you changed the both field values. Changing one legacy field value will not change the CL stage
Have Higher LC mapping pirority for "Install Status" field than "Operational Status" field.
- This means changing the "Operational Status" field value will not change the mapped LC stage/status when "Install Status" field have different LC mapping stage. ex: When you change the Operational Status as Retired for a Server where the install status as Installed, LC stage will not change to 'End of Life' as mapped for Operational Status.
Create a Business rule to enable synchronization between 'Install Status' to 'Operational Status' and use only the 'Operational Status' field with LC Mappings.

Re: Life Cycle Stage and Status vs Operational Status & Install Status

AJ_TechTrek — Mon, 04 Mar 2024 15:05:21 GMT

Hi @agamage ,

you can refer the CI deletion statergy.

https://docs.servicenow.com/de-DE/bundle/sandiego-employee-service-management/page/product/discovery/concept/deletion-strategy.html

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.

Thanks

Linkedin Profile:- https://www.linkedin.com/in/ajay-kumar-66a91385/

ServiceNow Community Rising Star 2024

Re: Life Cycle Stage and Status vs Operational Status & Install Status

schorsch — Fri, 23 May 2025 08:34:16 GMT

Hi,

there exists an (unfortunately) undocumented solution for this "problem" that only the legacy install_status field is set and not operational_status when a retired server is "again" found via discovery what results in a incorrect life cycle stage/ stage status field mapping.
When you look in the Pattern Pre/Post Script (table 'sa_pattern_prepost_script') "Update Server Status Fields" you'll find this:

The mentioned sys_property "glide.discovery.patterns.server_update_operational_status" doesn't exist ootb - so you need to create it with the value "true". When this is done and a retired server will be "found" again via discovery the install_status AND the operational_status will be set, so the lifecycle mapping will also getting affective (because of the higher priority of the operational_status in the ootb settings for the mapping).

best regards

Georg