Configuration Items

# Configuration Items

A configuration item (CI) is any piece of infrastructure the platform tracks and reasons about — a server, an application, a database, a network device, or a cloud resource.

## CI classes

Every CI class shares a common base: **Name**, **Operational status**, **Install status**, **Environment**, **Support group**, **Owned by** / **Managed by**, **Location**, **Manufacturer** / **Model**, the **Business service** it supports, an **Asset tag**, and a **Maintenance schedule**. Each class adds its own attributes on top:

| Class | Adds |
|---|---|
| **Server** | IP address, FQDN, server type (Physical / Virtual / Container Host / Cloud Instance), OS, CPU/RAM/disk. |
| **Application** | Application type (Web / API / Batch / Desktop / Middleware), version, URL, the server it runs on, vendor. |
| **Database** | Database engine (PostgreSQL, MySQL, Oracle, SQL Server, MongoDB), engine version, size, cluster/HA grouping. |
| **Network Gear** | Device type (Switch / Router / Firewall / Load Balancer / VPN Concentrator), port count, firmware, rack location. |
| **Cloud Resource** | Provider (AWS / Azure / GCP), resource type (Compute / Managed Database / Storage / Serverless / Queue), region, resource ID. |

**Operational status** (Operational / Degraded / Non-Operational / In Maintenance / Retired) and **Install status** (Installed-In Use / On Order / In Stock / In Maintenance / Retired-Decommissioned / Absent) are two independent choice fields rather than a single workflow — CI classes don't carry a state stepper the way task-based records do.

## Relationships

CI relationships are directed edges — a parent, a type, and a child — with types **Runs on::Runs**, **Depends on::Used by**, **Hosted on::Hosts**, **Connected to::Connected to**, and **Members::Member of**. The **Relationships** page lets you explore this graph directly; **Business Services** are themselves CIs that other CIs depend on or are hosted under, giving every service a rolled-up dependency tree.

## Service Maps

For each business service, **Service Maps** walks the relationship graph downstream (up to three tiers) to build the tree of CIs that deliver it — application, then server, then database or network gear — and rolls each node's operational status up into a single health band: **Healthy**, **At risk**, or **Critical**. KPI cards summarize how many services fall into each band; clicking any node in the tree deep-links into that CI's class list.

## CMDB Health & Data Certification

**CMDB Health** scores the CI estate on three axes — **Completeness**, **Correctness**, and **Compliance** — broken out by class, so you can see which class of infrastructure has the most data-quality debt. **Data Certification** surfaces the underlying work queue behind those scores: de-duplication tasks, duplicate CIs, stale CIs (not seen or updated recently), and incomplete records, each with a count linking into the CI list.

## Discovery sources

**Discovery sources** shows where the CMDB's data comes from — the identification and reconciliation sources feeding the CI estate — so you can see which systems are populating which classes.

A configuration item (CI) is any piece of infrastructure the platform tracks and reasons about — a server, an application, a database, a network device, or a cloud resource.

CI classes

Every CI class shares a common base: Name, Operational status, Install status, Environment, Support group, Owned by / Managed by, Location, Manufacturer / Model, the Business service it supports, an Asset tag, and a Maintenance schedule. Each class adds its own attributes on top:

Class	Adds
Server	IP address, FQDN, server type (Physical / Virtual / Container Host / Cloud Instance), OS, CPU/RAM/disk.
Application	Application type (Web / API / Batch / Desktop / Middleware), version, URL, the server it runs on, vendor.
Database	Database engine (PostgreSQL, MySQL, Oracle, SQL Server, MongoDB), engine version, size, cluster/HA grouping.
Network Gear	Device type (Switch / Router / Firewall / Load Balancer / VPN Concentrator), port count, firmware, rack location.
Cloud Resource	Provider (AWS / Azure / GCP), resource type (Compute / Managed Database / Storage / Serverless / Queue), region, resource ID.

Operational status (Operational / Degraded / Non-Operational / In Maintenance / Retired) and Install status (Installed-In Use / On Order / In Stock / In Maintenance / Retired-Decommissioned / Absent) are two independent choice fields rather than a single workflow — CI classes don’t carry a state stepper the way task-based records do.

Relationships

CI relationships are directed edges — a parent, a type, and a child — with types Runs on::Runs, Depends on::Used by, Hosted on::Hosts, Connected to::Connected to, and Members::Member of. The Relationships page lets you explore this graph directly; Business Services are themselves CIs that other CIs depend on or are hosted under, giving every service a rolled-up dependency tree.

Service Maps

For each business service, Service Maps walks the relationship graph downstream (up to three tiers) to build the tree of CIs that deliver it — application, then server, then database or network gear — and rolls each node’s operational status up into a single health band: Healthy, At risk, or Critical. KPI cards summarize how many services fall into each band; clicking any node in the tree deep-links into that CI’s class list.

CMDB Health & Data Certification

CMDB Health scores the CI estate on three axes — Completeness, Correctness, and Compliance — broken out by class, so you can see which class of infrastructure has the most data-quality debt. Data Certification surfaces the underlying work queue behind those scores: de-duplication tasks, duplicate CIs, stale CIs (not seen or updated recently), and incomplete records, each with a count linking into the CI list.

Discovery sources

Discovery sources shows where the CMDB’s data comes from — the identification and reconciliation sources feeding the CI estate — so you can see which systems are populating which classes.

Share feedback

Thank you!