Install Status vs Hardware Status on Hardware CIs

[Mike McCall]

I've got a simple question that doesn't seem to have a simple answer: should I have workers use [install_status] or [hardware_status] on my Hardware CIs? (i.e., those CIs that extend the [cmdb_ci_hardware] table)*

To get the discussion started, I'll lay out some factors I'm currently considering:

1. Install Status is available on all CIs, so views, reports, etc. can all be simpler and more consistent. Point for Install!
2. Install Status does not have a Substatus for being more specific (and closer to the choices available to Assets). Point for Hardware!
3. On Hardware CIs, the default "AssetAndCISynchronizer" Script Include (sys_script_include.do?sys_id=9ec37b411b012000e49bfbcd2c071380) does not sync Install Status changes to connected Asset records. Point for Hardware!
4. ...?

*I can't remember who the individual was--I would have contacted him!--but I vividly remember a ServiceNow employee swinging through a past Knowledge session and saying definitively, "Only use Install Status! Hardware Status was a mistake!" However, since uncovering just how deep this "mistake" goes in the system's default setup, I'm not sure it's so simple.

[Mike McCall]

I'm not sure I'll be able to confirm or deny if it was you, but I definitely appreciate the input now! (And I already had a separate tab open to read your 9-part Model blog, too.)

I like your point about the increased granularity of CI statuses not providing much value, and I think that #1 in my list is actually worth several points (meaning Install Status still seems like the way to go).

In terms of pre-Helsinki synchronization, what is your recommendation to keep the [install_status] values matching between CI and Asset? I know that "...ServiceNow, Inc. recommends updating status on the Asset form." I don't love updating default Script Includes, but I could also see potentially commenting-out the Hardware CI branch within "AssetAndCISynchronizer" (to always go from CI [install_status] to Asset State).

[Community Alums]

Michael,

You should not need to modify the default script includes at all. The State/Status synchronization is better defined from Asset State to CI Status, hence that recommendation. Also, the Install Status does not display on any forms by default, so to configure it to be the location at which you make changes, requires the modification of a lot of different forms. It is easy to use it as a filter, though, in any lists and reports.

The Install status does synchronize back, too. For example, if you set Install Status to Retired, it would set the Asset State to Retired. There is a little problem with this, though: You could retire a CI, but the Asset just goes back into stock to be repurposed later. Alas, this is also a great scenario where you would want to update the CI status directly, so it can be tricky.

Ben

[Mike McCall]

The CI Install Status not showing by default is brilliant. I can't even remember that far back in our system, but that would have simplified a lot!

As for the synchronization, I see three distinct scenarios:

1. Update CI Status on non-Hardware CI: Asset State/Substate are synced
2. Update CI Hardware Status/Hardware Substatus on Hardware CI: Asset State/Substate are synced
3. Update CI Status on Hardware CI: Asset State/Substate are NOT synced

Of course, as you mentioned, working from Asset is much cleaner:

1. Update Asset State/Substate on Hardware Asset: CI Status and CI Hardware Status/Hardware Substatus are synced
2. Update Asset State/Substate on non-Hardware Asset: CI Status is synced (and CI Hardware Status/Hardware Substatus don't exist)

[Mike McCall]

I know at least one person who feels that the Hardware Status/Substatus pair offers:

1. a more consistent experience for Hardware CIs* because of the matching values and fact that the synchronization is bi-directional (which is not universally the case as of Fuji Patch 10)
2. status granularity that you may really want (especially when you're looking at a Hardware CI that doesn't have an associated Asset)

However, it's tough to argue with you, Ben, so I'm going to mark your answer as "Correct" and selfishly mark this reply as "Helpful" (at least until someone else echoes these points and/or adds their own reasons to champion Hardware Status/Substatus). Thanks!

*As stated earlier, using Hardware Status/Substatus for Hardware CIs leaves you at a loss when viewing higher-level CI lists.

[Nickels]

Hey Ben, 

I had a couple questions regarding this topic and wondered if you might be able to help me. We reset our instance last fall so that we could get 'back in the box' and really try and adopt ServiceNow processes. We worked with a consultant, which made a recommendation of using Hardware status and added it to several CMDB tables but I'm working with Windows Servers specifically here. They also setup both Asset-CI Install Status mapping and also the Asset-CI Hardware Status Mapping.

We are trying to mature our CMDB, so the questions I have are:

1. Since this is an older thread, do you still recommend only using Install status on the CI records and completely ignoring the Hardware status? 

2. I think by having both the mappings setup under the Asset heading is causing a conflict. It appears that the Asset-CI install Status mapping is ignored and only the Hardware status mappings are working. Would it be correct in saying we should only have mappings in one of those tables and not both?

Appreciate your time!

-Chris