Install Status, Hardware Status or Operational Status?

[mbourla]

Am revisiting this old question, to understand which status field to use on CIs - install_status, hardware_status or operational_status.   Would be keen to know what other people are doing around this.

The 3 OOTB status fields are:

• hardware_status (and hardware_substatus) : defined on cmdb_ci_hardware, so only available for hardware.
• install_status : defined on the cmdb table (in recent versions, previously cmdb_ci), so can be used on all CI types (including hardware)
• operational_status : defined on cmdb_ci, so can be used on all CI types (including hardware).

https://community.servicenow.com/thread/221800 says that hardware_status is legacy, so to use install_status.

https://docs.servicenow.com/bundle/istanbul-servicenow-platform/page/product/configuration-managemen... describes how operational_status is sync'd with hardware_status (on hardware CIs) or with install_status (on non-hardware CIs).   I didn't know that before. But from experimenting, it only syncs operational_status with one or other of install_status and hardware_status, not both.   Which isn't terribly helpful (but can be customised of course).

https://community.servicenow.com/message/840145#840145 advises to ignore operational_status and use install_status.

So the conclusion so far is to go with just install_status for all CI types.

But... from https://docs.servicenow.com/bundle/istanbul-servicenow-platform/page/product/configuration-managemen... it's operational_status which the new CI Lifecycle Management works with.

Which implies that ServiceNow intend people to use operational_status as the primary status field.

So the question is... to stick with install_status, which keeps things simple?   Or use operational_status, to allow future use of CI Lifecycle Management?   Or use both install_status AND operational_status, where I'd see operational_status being like a sub-status for install_status (and the choices tweaked to remove the overlap & duplication).

Thoughts welcome!!

Thanks

Michael

[Chris Bui]

You are right Paul. 

It appears that hardware_status is NOT legacy.  It is paired with hardware_substatus and applies to all classes that stem from cmdb_ci_hardware.  

Michael's original statement that "operational_status as the primary status field" seems to be true as well since it's involved with "CMDB CI Lifecycle Management".

Here are some links for continued reading.

https://docs.servicenow.com/bundle/paris-it-asset-management/page/product/asset-management/concept/c_ManagingAssets.html

https://docs.servicenow.com/bundle/paris-servicenow-platform/page/product/configuration-management/concept/cmdb-ci-lifecycle-mgmt.html

[mbourla]

To muddy the waters further, I have just noticed that in our instances there is now a new field service_status on cmdb_ci_service.  Don't know when it came in.  It's not in a vanilla ServiceNow instance so must have been added by a plugin that we've installed.

But that means that on Service CIs, there are now 3 status fields:

• Operational status [operational_status]
• Status [install_status]
• Status [service_status]

And not at all confusing that the last two have the same label!!

The new service_status has values like Requirements, Analysis, Design etc.  It is dependent on a Phase field.  

[Chris Bui]

Muddy waters is an understatement! As with everything ServiceNow, it's up to how it works for you and your overall IT process maturity. 

Thankfully, ServiceNow has been more prescriptive in this area with their continued development of the CSDM.  I think the fields you mention are part of this.

The CSDM and CMDB courses in now learning on my short list of things I need to dive deeper into.

https://community.servicenow.com/community?id=community_article&sys_id=b96b84e7db5fd85011762183ca9619c9=

https://nowlearning.service-now.com/lxp?id=overview&sys_id=c120bb5bdbd0c8103e3aaca2ca9619bf&type=path