Life Cycle VS Operational status

[Alexandre]

Hello,

I am looking to use the CMDB data manager to manage Stale CIs in the CMDB. Instead of using the remediation rules and workflow which are difficult to maintain and improve. However, currently, we manage the life cycle of CIs by the attributes 'operational status' and 'status'. The CMDB data manager will only work with the "life cycle stage" and "life cycle status".

What is the good practice, what is the vision of Service Now about this topic ?

Should we stop using the 'operational status' and 'status' and go through the Life cycle?

Should we put a rule so that the 'operational status' and 'status' = the Life cycle?

=> What are the best practices for using “life cycle stage” and “life cycle status” (at the global level, not only at the cmdb data manager level) and what are the differences with operational status and status?

Thanks a lot for your help. 

Alex

[Alexandre]

Hi Maik, Tony,

Thanks for the answers. It was really helpful. I would just like a little additional clarification.

By imagining that the mapping between the legacy fields (e.g. operational status) and the Lifecycle Stage field is functional. And if we use the policies of the CMDB Data manager to manage the Stales for example.

I understand that the Lifecycle Stage fields will inherit from the legacy fields. But is this also the case in the other direction? How will the legacy fields behave when the CMDB Data manager changes the Lifecycle Stage field? If a CI is changed to Retired.

Will the operational status remain in the same state (operational for example)? We would then have two contradictory values. I think it's bi-directionnal but I wanted more information about that (limits, how it works, advice...) 

An other point. Can the operational status and status fields both be mapped to the life cycle?

Thanks for your help. 

Kind regards,

Alexandre. 

[Tony Branton]

Hi Alexandre,

Sync from legacy fields to Life Cycle fields is unidirectional by design.  As mentioned earlier, you can continue to use legacy fields however if you intend to start using the new Life Cycle fields for specific use cases (e.g. Asset Management) then you should cut over to the new fields i.e. cease using the legacy fields.

For the CI retirement use case, if you're using CMDB Data Manager you're typically retiring a CI as a pre-requisite for archiving or deleting the CI. If your intention is to retain a retired CI record for use in the future, then you're better off putting the CI in a non-operational state rather than retired.

It's possible to map more than one status field to a Life Cycle Stage / Life Cycle Stage Status set. In this case you can assign a priority order to the mappings to indicate which one would take precedence over another.

Hope this helps.

[PG2]

Hi Tony, we're activating the new life cycle stage / states. While mapping the legacy operational states we came across a business rule called 'Life Cycle Mapping Uniqueness' preventing us from mapping two different stage/states back to a single operational status.

For example, we want Deployed to map to Operational/In Use (and kept in sync). This is all good. However, we also want to start leveraging the new Operational/Pending Retirement stage/state for a new use case. Ideally, we want to map this back to Deployed. Note that we don't have an equivalent legacy operational status for pending retirement and don't want to create one because we are trying to move away from the old stuff.

The aforementioned business rule prevents us from configuring a one way reverse mapping. Do you have any information about the intent / purpose of this business rule?