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.

[Johannes]

Great post @CMDB Whisperer!
This is way too complex for our users to comprehend, and that is a serious problem.
I am definitely also looking forward to the day the new CSDM Lifecycle standards have fully replaced the other status attributes. 

Regarding Operational Status = Retired:

---

There is was a business rule "Retire/revive CI" on cmdb_ci_vm_instance (it has now been replaced by "Reconcile VMs on state change") setting Operational Status to Retired "if the VM state is terminated, and the VM still exist in the Cloud Provider":
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0859758

Then there is a business rule "Cascade deprovisioned status to Server" (two if you have both Discovery and Service Mapping) setting Operational Status to Retired if VM is Retired:

"This business rule "Cascade deprovisioned status to server"  was added as a fix for a PRB1408405.
The issue addressed in the PRB1408405 is below:
When we receive notification (e.g. from vCenter, AWS, etc) that a VM has been deprovisioned, we mark the corresponding CI in such a way as to remove it from subsequent daily license counts. However, when that VM is linked to a Server CI (of type cmdb_ci_server or subordinate), that CI is not similarly marked. This causes the daily license count to not be reduced. The deprovisioned status needs to be carried through to the linked Server CI in order to properly reduce the subsequent daily counts. The VM CI will be marked "teminated/retired" but its linked Server CI will not, which will cause ITOM Visibility & Health license counting to be inaccurate."
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0863733

Our users gets confused when Operational Status is Retired and Status is not, so it is tempting to sync this value, but there are multiple reasons why this should not be done.
(And since users often use list view, hiding the attribute from the forms also does not help much.)
...what a bloody mess. "Statusgate!" 😅

[Johannes]

Yet another pretty confusing status value thing:

cmdb_ci_business_app uses value 3 for install_status = Retired

Most (all) other tables are using value 7.
This creates som "funny" situations, like if you want to search for relations where Business Applications is having install_status set to "Retired", you must search for the ones having install_status set to "In Maintenance" 🤣

 

Is ServiceNow aware of this inconsistency...@Barry Kant?

[Nachiketh Rahul]

May be this helps your Cause

[Johnathan R]

I just wanted to say this is an incredibly useful post!! THANK YOU

[VaranAwesomenow]

Thanks @CMDB Whisperer very insightful inputs, adding to that @Suggy  ServiceNow doesnt allow you to set Operational status and Install status to all possible combinations, for example you cannot have install status = Installed and Operational status = retired, it tries to check and reset one of the two depending on which one is updated last

For example : If install status = installed and if you try to set operational status = retired it will set it to operational

this is driven by business rule 

https://<instancename>.service-now.com/nav_to.do?uri=sys_script.do?sys_id=2a7ce2841b832010dd7b6395604bcb70