Install Status vs Hardware Status vs Substatus vs Operational status vs Lifecycle stage status fields on the CI form?

[Suggy]

So many status fields on the CI form --> Install Status vs Hardware Status vs Substatus vs Operational status vs Lifecycle stage status

Which fields to use in which situation, along with Asset status fields.

PS- again there are so many posts on this topic but totally confusing. If any one has got proper clarity on this, please do share.

[sachin_namjoshi]

They have different purpose :

1. Install status is applicable for both assets and CIs.
2. Hardware Status is applicable for only hardware CIs( e.g servers, ). But, this isn't used anymore. 
3. Substatus depends on install status.
4. Operational status tells where CI is in maintenance mode, live or being retired.
5. If you activate the CSDM framework, you can start using the two new fields, Life Cycle Stage and Life Cycle Stage Status to track an asset's life cycle.

Regards,

Sachin

[CMDB Whisperer]

Correction on #3.  Substatus is dependent on Hardware Status, not on Install Status.  See my response below.

[CMDB Whisperer]

Status (install_status) is on all CI classes and also synchronizes with the Install status and Substatus field on the Asset table, with some caveats (see below.)  The meaning of the install status is loosely but broadly considered to be the primary indicator of the state of the CI in its overall lifecycle.

Hardware status (hardware_status) is only applicable to Hardware CIs.  One major down-side here is that if you use it, you do not have a single status field that you can rely on to tell you about the status of a CI.  In addition, if you look at the actual values, you will see that they have more to do with asset management in many cases than configuration management.  For example, they contain states of In Transit and Pending Disposal.  

Substatus (hardware_substatus) is dependent on Hardware Status, not on Install status.  While the State (install_status) field on the Asset table does have a Substate (substatus) field, the Status (install_status) field on the CI table does NOT have a substatus.

For all of the reasons above and more, I do not recommend using the Hardware status or Substatus fields.  You will generally get better and more intuitive behaviors if you just stick to using Status (install_status) for CIs, and do not use Hardware status or Substatus.  Again, see caveat below.

Caveat: Out of box, ServiceNow assumes that you are using Hardware status for Hardware CIs.  Thus, despite assumptions and appearances, your CI Status and Asset State will become out of sync, through normal use of the platform, which will cause lots of issues with your asset management and configuration management processes, and will decrease confidence in your data and in your processes.  To remedy this you just need to make a necessary modification to the Asset/CI synchronization code which will cause the Status field to become the authoritative status for all CI classes.  This change is documented in the following ServiceNow KB article.  ServiceNow doesn't acknowledge this as a bug, but at least it gives you a simple solution: https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0717902  Once you have this in place, you should have your Status fields updating consistently and correctly in both directions.

The Substate on the Asset table in many cases provides information that is only relevant from an asset management perspective, although in some cases it does affect the CI Status value, but in either case it shouldn't trouble you that you no longer have a CI substatus field because those mappings have already been worked out for the most part.  If you find you have to modify those Asset/CI state mappings you can do so by adjusting the records in the Asset CI Install Status Mapping table (alm_asset_ci_state_mapping).

OK so now you have your Status figured out, right?  But what about Operational Status?  Well the idea for this one is that it generally is there to indicate whether the device is fully operational, reachable, and working as expected.  Note that this is distinct from whether or not it is installed.  Therefore it is not synchronized at all with any other status field and this is by design.  You may find that this is still confusing, primarily because it shares some values such as Retired with the Install Status field.  But that's really there to say "it's neither operational nor non-operational; it's retired, so you don't have to worry about it being non-operational"  I have seen some customers simply disable some of the choices for Operational Status for that very reason, leaving only Operational and Non-operational, to avoid this confusion.  Since the Install Status already includes an option for Retired, it is redundant to define this on Operational Status as well.

So that's it, right?  Well, not really.  When you look at Business Applications you will see that the values are different there.  And when you look at the Service class, you will see that it also contains status fields for the service design pipeline and the service catalog.  Not to mention that you have to think about different status fields with different values and semantics for other foundational tables like Models, Locations, and Contracts.  It's dizzying.  "Calgon take me away!!"

And this brings us to the Lifecycle Stage and Lifecycle Status fields.  These are defined as part of the Common Service Data Model, which exists to standardize the way we do things in the CMDB.  The purpose of these fields is not to further confuse things regarding lifecycle.  Rather, it is to provide a light at the end of the tunnel.  A single language to define the lifecycle of anything.  This single language ultimately will make everything simpler.  Eventually.  Unfortunately, as of the San Diego release, much of the business logic in the system (as well as in customer-defined logic!) still has dependencies on the legacy status fields, so we can't make full use of the Lifecycle Stage/Status fields yet.  But we can opt in anyway, as ServiceNow has provided mappings from the legacy fields, so that as you update the legacy fields, the Lifecycle fields will be updated automatically.  This enables customers to start establishing the correct value of Lifecycle on the back-end without having to worry about whether the field is fully supported in the various ServiceNow modules.  This enables you to create reports or custom business logic in ServiceNow using these emerging standard fields, so that in the future when ServiceNow ultimately completes the full enablement of these fields, you are all set to go!

TL;DR - Most customers will get the best results by doing the following:

1. Add the Status (install_status) and Operational status (operational_status) fields to all CI forms and lists where CI lifecycle is being tracked.
2. Remove the Hardware status (hardware_status) and Substatus (hardware_substatus) fields from all Hardware CI forms and lists (or simply deactivate the dictionary entry entirely)
3. Modify the AssetAndCISynchronizer field as indicated in KB0717902.
4. Review your use of the various status fields and mappings and then carefully migrate to CSDM Lifecycle standards but only when you are absolutely sure it's fully tested with all ServiceNow products, and any custom reports, business rules, etc.  
   NOTE: Do not add these fields directly to your CI or Asset forms/lists yet, as this will cause unnecessary confusion with your users, as they will be effectively unable to set these values directly! 

UPDATE: as of Vancouver, in theory the CSDM Life Cycle fields have been updatable bidirectionally for the last several releases, but I still do not recommend enable writing to these for Asset and CI tables yet, because my testing has shown that the synchronization between Life Cycle fields and legacy status fields, combined with the synchronization between Asset fields and CI fields is simply too complex to be reliable.  A better synchronization solution is needed before these fields should be relied upon for CIs or Assets (though you can use them for Locations and other objects).  If you do use them on CI or Asset fields, make them Read Only to prevent issues with the bi-directional synchronization.  They still aren't 100% reliable even with one-way synchronization, but at least they are probably not much less reliable than the standard Asset-CI status synchronization.  A better solution to this synchronization is still needed!

UPDATE: as of Washington DC, the bidirectional integration seems to be working in most cases, actually it has passed all of my test cases.  It's still a complex synchronization so I would still be cautious and monitor your data to ensure you don't end up with out-of-sync asset and CI status.  And still apply the fix documented in the KB article linked above, and deactivate your hardware status and substatus fields as they are deprecated and should no longer be used!

UPDATE:  As of Xanadu and Yokohama I am updating my recommendation to hold off on CSDM Life Cycle Management for the foreseeable future.  Per the CSDM 5 document, it seems very clear that it is NOT ready for prime time.  Every indication seems to be that ServiceNow is still figuring out a path for customers to migrate to CSDM Life Cycle -- either that or they are leaving it to customers to figure out their own path.  As mentioned above, the Washington release passed my synchronization tests, so although I was a bit cautious still because ultimately I wasn't convinced that the chained business rule  logic approach to synchronization would ever be a workable approach (and still am not), I reluctantly started giving the tentative thumbs-up for adoption.  But lo and behold, the very next release they discontinued support for Life Cycle Mapping synchronization and introduced a new thing called Product Instance 2.0 as a replacement, but there are not enough details available about this solution for me to confidently say when CSDM Life Cycle will get a thumbs up from me.  But I will update this article if and when that changes.  Thanks for reading!

[CMDB Whisperer]

UPDATE: Looking more deeply at the Retired value of Operational Status there does appear to be a default mapping to the Pending Retirement lifecycle stage, which previously was not the case.  Based on this I would modify my statement above that setting Operational Status to Retired is redundant.  Rather, setting Operational Status to retired would be used for a CI that is no longer in use but is still pending a decommission process.  In this case the Status (install_status) could be Installed while the Operational Status is Retired.  

Looking forward to the day when this isn't so complex!