Life Cycle Stage and Status vs Operational Status & Install Status

agamage
Tera Contributor

‎03-03-2024 04:45 PM

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: 

LifeCycleMapping_(cmdb_ci_server).JPG

 


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? 

  1. 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
  2. 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.  
  3. Create a Business rule to enable synchronization between 'Install Status' to 'Operational Status' and use only the 'Operational Status' field with LC Mappings. 

 

 

 

 

 

 

 

 

 

0 Helpfuls
  • 2,282 Views
2 REPLIES 2

AJ-TechTrek
Giga Sage
Giga Sage

‎03-04-2024 07:05 AM

Hi @agamage ,

 

you can refer the CI deletion statergy.

 

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

 

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

AJ

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

ServiceNow Community Rising Star 2024

0 Helpfuls

schorsch
Tera Contributor

‎05-23-2025 01:34 AM

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:

schorsch_0-1747988709130.png

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