The CMDB Status Field Problem
You open a CI record in the ServiceNow CMDB and see a cluster of status-related fields: Operational Status, Install Status, Hardware Status, Life Cycle Stage... and you have no idea which one to use.
You're not alone. This is one of the most common points of confusion for ServiceNow administrators, developers, and even architects working with the CMDB. The naming is vague, the documentation is scattered, and getting it wrong has real consequences — from broken reporting to failed audits to CMDB Health scores that make stakeholders nervous.
Let's cut through the confusion once and for all.
The Two Status Fields That Actually Matter
Forget the five or six status-sounding fields on a CI for a moment. In practice, there are really only two that matter for day-to-day CMDB management:
- Operational Status — What is this CI doing right now?
- Install Status — What is the state of the physical or logical asset?
Here's the critical distinction: Operational Status describes the CI's role in your infrastructure. Install Status describes the asset's lifecycle state.
Operational Status: The Field You Should Be Using
The operational_status field answers the question: "What is this CI doing in our environment right now?"
Common values include:
- Operational — Live, in production, doing its job
- Non-Operational — Exists but not currently functioning
- Repair in Progress — Being fixed
- DR Standby — Disaster recovery standby
- Ready — Provisioned but not yet in production
- Retired — Decommissioned, no longer in use
This field is available on all CI classes (servers, network gear, databases, applications, services — everything). It does not sync with the Asset record.
If you're only going to maintain one status field on your CIs, make it this one.
Why Operational Status Gets Neglected
Here's something that surprises a lot of people: Operational Status isn't on the form by default for most CI classes. ServiceNow ships the platform this way, and it's frankly a strange decision. If you're managing CI state — and you should be — add this field to the form layout for at minimum:
- Servers (
cmdb_ci_server) - Network Gear (
cmdb_ci_netgear) - Database Instances (
cmdb_ci_database) - Applications (
cmdb_ci_appl) - Any CI class where you track operational state
Install Status: The Asset Team's Field
The install_status field answers a different question: "What is the physical or logical state of this asset?"
Common values include:
- Installed — Physically deployed
- In Stock — In inventory, not yet deployed
- On Order — Purchased, awaiting delivery
- Retired — End of life
- Stolen — Reported missing/stolen
- Absent — Can't be located
The critical difference: Install Status syncs between the CI and its linked Asset record. When the Asset Management team changes the State/Substate on the alm_asset record, that change flows to the CI's Install Status via the Asset CI Install Status Mappings table (alm_asset_ci_state_mapping).
This is where it gets tricky. Assets use a two-field system (State + Substate) while CIs use a single field (Install Status). The mapping between them is configurable but not always intuitive.
Rule of thumb: Let the Asset Management team own Install Status. Don't manually override it on the CI side unless you understand the sync implications.
Do They Sync With Each Other?
No. Operational Status and Install Status are completely independent. Changing one does not affect the other.
This means you can have a CI where:
- Operational Status = Operational
- Install Status = Stolen
...and ServiceNow won't flag that as a problem unless you tell it to.
Build Health Rules to Catch Mismatches
This is where CMDB Health Certification rules become essential. You should create rules that flag logical inconsistencies between these fields. For example:
- All Server CIs where Operational Status is "Operational" should have Install Status of "Installed" or "Pending Repair"
- Any CI with Install Status "Retired" should not have Operational Status "Operational"
- CIs with Install Status "Stolen" or "Absent" should have Operational Status "Non-Operational"
These rules won't fix themselves, but they give you visibility into data quality issues before they cascade into incident routing failures or inaccurate reports.
Real-World Examples
Example 1: Physical Network Router
A Cisco switch racked in your primary datacenter:
- Operational Status: Operational (it's routing traffic)
- Install Status: Installed (the hardware is physically deployed)
Both fields align. Simple.
Example 2: Virtual Server
A VMware virtual machine running your test environment:
- Operational Status: Operational (the VM is running)
- Install Status: Installed (technically there's a linked asset, but it's a VMware "Manufacturer" asset created by discovery — the field doesn't carry much meaning for virtual infrastructure)
For virtual CIs, Operational Status is the only field that really matters.
Example 3: Decommissioned Server
An old physical server being pulled from the datacenter:
- Operational Status: Retired (no longer serving traffic)
- Install Status: Retired (the Asset team processed the hardware return)
Both fields should be updated, but they'll be updated by different teams at different times.
Example 4: Service Offering
A business service like "HR Portal":
- Operational Status: Operational (the service is live)
- Install Status: Not meaningful — service offerings aren't physical assets
For non-technical CIs (services, service offerings, business applications), only Operational Status applies.
Life Cycle Stage: The CSDM Replacement
Starting around the Rome release, ServiceNow introduced Life Cycle Stage and Life Cycle Status fields as part of the Common Service Data Model (CSDM) framework. These are intended to replace the legacy status fields:
- Operational Status (legacy)
- Install Status (legacy)
- Hardware Status (legacy)
The Life Cycle fields align to CSDM lifecycle definitions and are available on all CIs plus some Foundation Data tables like Locations.
Should You Migrate?
If you're implementing CSDM — and with the direction ServiceNow is heading, you probably should be — then yes, plan a migration from the legacy status fields to Life Cycle Stage/Status. ServiceNow provides migration utilities to help.
If you're not doing CSDM yet, stick with Operational Status. It's well-understood, well-supported, and won't be removed anytime soon.
The Other Status Fields (Quick Reference)
Hardware Status
Only applies to hardware CIs (cmdb_ci_hardware subclasses). Largely deprecated. ServiceNow replaced this with the Life Cycle fields. If you see it on a form, it's likely vestigial.
Firewall Status
Found on Server CIs. Indicates whether the server is internet-facing, intranet-only, or in the DMZ. This is a classification field, not a state field. It answers "where does this server sit in the network?" — not "is it operational?"
Attestation Status
Part of the CI Attestation feature. Tracks whether a CI has been verified by an owner or support engineer. Useful for bulk-imported CIs where you need human confirmation that the data is accurate.
Decision Framework: Which Field Should I Use?
ScenarioUse This FieldTracking whether a CI is live, standby, or retiredOperational StatusManaging physical asset lifecycle (procurement → retirement)Install Status (via Asset)Implementing CSDMLife Cycle Stage + StatusImporting CIs from a spreadsheet with a "Status" columnOperational Status (99% of the time)Classifying network exposureFirewall StatusValidating bulk-imported CI dataAttestation Status
Key Takeaways
- Default to Operational Status for CI state management. It's universal, doesn't sync with assets, and is the most commonly needed field.
- Leave Install Status to the Asset team. It syncs with the Asset record and should be managed through the ITAM lifecycle, not ad-hoc CI updates.
- They don't sync with each other. Build CMDB Health rules to catch mismatches.
- Add Operational Status to your CI forms. ServiceNow doesn't do this by default — fix that.
- Plan for Life Cycle Stage/Status if you're adopting CSDM. It's the future direction, even if the legacy fields aren't going away immediately.
Getting these fields right is foundational. Every report, every automation, every CMDB Health dashboard depends on accurate status data. Nail this, and the rest of your CMDB program gets a lot easier.