2.1 CI Class Manager and Hierarchy Architecture

CI Class Manager and Hierarchy Architecture

In ServiceNow, the Configuration Management Database (CMDB) is structured as a class hierarchy, representing a logical taxonomy of all IT infrastructure and service components. The design of this hierarchy determines how data is stored, how queries perform, and how classes inherit attributes and configurations. Understanding how table inheritance maps configuration items to classes is a critical skill for any ServiceNow Certified Implementation Specialist.

The Core Foundations of the CMDB Schema

At the heart of the CMDB is the Configuration Item [cmdb_ci] table. This is the base, or root, class from which all other configuration item tables descend. Any table that extends cmdb_ci is considered a CMDB class, and its records are called Configuration Items (CIs).

ServiceNow distinguishes between classes using a hierarchical model. For example, a Linux Server is a specific type of server, which is a type of computer, which is a type of hardware, which is a configuration item. This structure is mirrored in the database tables:

• Base Class: Configuration Item [cmdb_ci]
• Parent Class: Hardware [cmdb_ci_hardware]
• Child Class: Computer [cmdb_ci_computer]
• Grandchild Class: Server [cmdb_ci_server]
• Leaf Class: Linux Server [cmdb_ci_linux_server]

This hierarchical design allows ServiceNow to represent physical devices, logical instances, applications, and services in a unified structure while maintaining the specific relationships and attributes of each component type.

Table Inheritance and Schema Design

ServiceNow leverages table inheritance to enforce consistency across the CMDB. When a child class extends a parent class, it automatically inherits several foundational components:

1. Attributes (Columns): Every column defined on the parent table is automatically available on the child table. For example, the ip_address field defined on cmdb_ci is inherited by all descendant tables down to the leaf classes.
2. Identification and Reconciliation Rules: Core metadata configurations cascade down the hierarchy unless explicitly overridden at a child class level.
3. Scripts and Policies: Business rules, client scripts, and UI policies defined on a parent class apply to child classes as well.

This inheritance model ensures data normalization. Common properties are stored once at the highest logical level, while class-specific properties are added only at the level where they become relevant. For instance, the cpu_count attribute is not relevant for a base cmdb_ci record, but it is relevant for a cmdb_ci_computer, so it is defined at the computer level and inherited by all servers.

Dictionary Overrides and Inherited Attributes

When a field is inherited from a parent class, its definition in the System Dictionary (sys_dictionary) is shared across all child tables. However, administrators often need to change the behavior of an inherited field for a specific child class without affecting the parent or sibling classes. This is achieved using Dictionary Overrides.

A Dictionary Override allows you to customize the following properties for a child class:

• Default Value: Set a class-specific default value (e.g., default value of sys_class_name or asset_tracking_strategy).
• Mandatory / Read-only: Force a field to be mandatory or read-only only for that class (e.g., serial_number is mandatory for Servers but optional for general CIs).
• Attributes: Set specific database attributes (e.g., custom attributes for search or UI displays).
• Reference Qualifiers: Limit the options available in reference fields based on the class.

The CI Relationship Table: cmdb_rel_ci

While CIs themselves are stored in the hierarchy extending cmdb_ci, the connections between them are stored in the CI Relationship [cmdb_rel_ci] table. This table is not part of the cmdb_ci inheritance chain. Instead, it operates as a junction table that connects a Parent CI to a Child CI via a defined Relationship Type (e.g., "Runs on::Hosts", "Depends on::Used by"). Keeping relationships separate from CI attributes allows for dynamic, many-to-many relationship mapping without altering table schemas.

---

Logical vs. Physical Tables & Database Storage Models

ServiceNow abstracts the underlying database structure from administrators, but the physical storage model has major performance implications. The platform supports three main extension models:

Understanding these models is essential when designing custom classes, as table layout directly impacts transaction speeds and API throughput during high-frequency discovery ingestions.

---

The CI Class Manager: The CMDB Control Center

The CI Class Manager is the unified administrative interface for managing the CMDB hierarchy. It replaces legacy list and form views for configuring class settings, providing a visual, structured console.

Key Capabilities of CI Class Manager

Administrators use the CI Class Manager to perform several critical functions:

• Hierarchy Visualization: Navigate the class tree to see parent-child relationships and locate specific tables.
• Class Settings & Definitions: View display names, table names, and whether a class is extensible (can be parented) or active.
• Attribute Management: Review inherited columns and create new, class-specific fields.
• Identification & Reconciliation Engine (IRE) Configuration: Author identification rules, reconciliation rules, data source precedence, and multisource settings.
• CMDB Health KPIs: Configure class-specific thresholds for completeness, compliance, and correctness.

Class Attributes & Extensibility

When analyzing a class in the CI Class Manager, attributes are marked with visual indicators to show their origin:

• Inherited Attributes: Columns defined on parent tables. These are displayed in read-only formats in some settings, though they can be overridden using dictionary overrides if needed.
• Added Attributes: Columns defined directly on the selected class. These apply only to this class and its descendants.

It is a critical design principle to avoid "attribute bloat." Creating too many custom columns or adding columns at too high a level in the hierarchy degrades database performance and increases complexity.

---

Designing and Extending the Hierarchy

When new technology must be modeled in the CMDB, administrators face a choice: use an existing class, extend an existing class, or create a new base class.

• Use Existing Class: Map new components to an out-of-the-box (OOTB) table. Use this strategy when the component aligns with an existing table (e.g., a new type of web server matching cmdb_ci_web_server).
• Extend Existing Class: Create a new table that descends from an OOTB class. Use this when the component has unique attributes, identification rules, or lifecycle logic, but still fits under an existing parent (e.g., extending cmdb_ci_server to create a custom IoT Gateway class).
• Create New Class under cmdb_ci: Create a new table directly extending the root cmdb_ci table. Use this only when the technology is entirely novel and does not fit into any existing branch (e.g., a specific non-hardware cloud resource).

Class Lifecycle: Upgrades, Downgrades, and Switches

The sys_class_name attribute is a system-maintained field on every CMDB table that specifies the specific class of the CI. Changing the value of this field changes the CI's class. The platform classifies these transitions as:

• Class Upgrade: Moving a CI down the hierarchy to a more specific class (e.g., upgrading a Computer to a Server). The CI gains access to the new child class attributes.
• Class Downgrade: Moving a CI up the hierarchy to a less specific class (e.g., downgrading a Server to a Computer). Child-specific attributes not present in the new parent class are lost or hidden.
• Class Switch: Moving a CI horizontally to a sibling class (e.g., switching a Linux Server to a Windows Server). Attributes unique to the old sibling class are replaced by those of the new sibling.