Configuration
This domain validates your understanding of CMDB architecture, table hierarchy, class modeling, and CI data quality foundations. Strong mastery here is critical, as these concepts directly impact identification, reconciliation, and CSDM alignment.
CMDB Table Structure (Core vs Subclass Tables)
The ServiceNow CMDB uses a hierarchical table structure where core (parent) tables define common attributes, and subclass (child) tables extend them with more specific attributes.
Core (Base) Tables
Provide common attributes shared by many CI types. Act as parent tables in inheritance.
- cmdb_ci (top-level)
- cmdb_ci_hardware
- cmdb_ci_computer
Subclass (Child) Tables
Inherit all attributes from parent and add specialized fields.
- cmdb_ci_server
- cmdb_ci_linux_server
- cmdb_ci_win_server
CMDB Table Hierarchy
| Level | Table |
|---|---|
| 1 | cmdb_ci |
| 2 | cmdb_ci_hardware |
| 3 | cmdb_ci_computer |
| 4 | cmdb_ci_server |
| 5 | cmdb_ci_linux_server / cmdb_ci_win_server |
Queries against a parent table return records from all child tables. Identification rules defined at higher levels apply to children. Avoid custom tables when an existing subclass fits. Don't confuse class hierarchy with CI relationships. Child tables DO inherit identification rules.
cmdb_ci is the root of all CI classes. Subclass tables extend, not replace, parent attributes. Always model CIs as low in the hierarchy as practical.
CI Class Manager
The CI Class Manager is the ServiceNow tool to view, manage, and extend the CMDB class hierarchy.
CI Class Manager Capabilities
| Capability | Description |
|---|---|
| View hierarchy | Visualizes parent-child CI relationships |
| Create classes | Extends existing classes |
| Add attributes | Define fields specific to a class |
| Mark abstract | Prevents direct CI creation |
Abstract vs Non-Abstract Classes
| Type | Description | Example |
|---|---|---|
| Abstract | Structural only — no CI records can be created | cmdb_ci_hardware |
| Non-Abstract | Allows CI creation | cmdb_ci_server |
Best Practices
- Extend existing OOTB classes instead of creating new roots
- Use abstract classes for logical grouping
- Keep custom classes minimal to avoid CSDM conflicts
sn_cmdb_admin + personalize_dictionary roles are required for CI class management.
CI Class Manager does NOT manage CI records, only structure. Abstract classes cannot contain CI instances. Custom fields added to a parent appear in all children. CI Class Manager does NOT control identification rules.
Principal Class
The Principal Class filter controls which CI classes appear in ITSM reference fields (like the CI field on Incident, Change, and Problem forms).
- Only classes marked as Principal Classes show up when users search for CIs in ITSM forms
- Used to prevent low-level components (hard drives, NICs) from cluttering CI selection
- Configured in CI Class Manager under Principal Class settings
Independent vs Dependent CIs
Independent CIs
Can be identified on their own (e.g., servers, computers). Their identification rules use attributes from the CI itself (serial number, FQDN).
Dependent CIs
Require a parent CI to be identified first (e.g., network interface cards, disk drives, software installations). Their identification includes a reference to the hosting/parent CI.
The IRE processes independent CIs first, then dependent CIs. If the parent CI fails identification, dependent CIs get a MISSING_DEPENDENCY error.
Dependent CIs (like applications, NICs) require parent match first. The parent CI must be successfully identified before the dependent CI can be processed.
CI Attributes, Identifiers, and Normalization
CI Attribute Types
| Type | Purpose | Examples |
|---|---|---|
| Descriptive | Informational | Name, Location |
| Technical | System-specific | Serial Number, IP |
| Identification | Used to uniquely identify | Serial Number, FQDN |
Identifiers
Identifiers are combinations of attributes used by the IRE to determine CI uniqueness. They are defined per CI class, evaluated in priority order, and must uniquely identify a CI.
Example Identifier Priorities
| Priority | Identifier |
|---|---|
| 1 | Serial Number |
| 2 | Name + IP Address |
Normalization
Normalization ensures consistent, standardized CI values regardless of source. Uses Normalization Data Services (NDS).
- Manufacturer names
- Model names
- OS values
Identification vs Normalization
| Aspect | Identification | Normalization |
|---|---|---|
| Purpose | Detect uniqueness | Standardize values |
| Engine | GIE / IRE | NDS |
| Timing | Before reconciliation | During data processing |
Reconciliation Rules
Reconciliation rules control which data sources are authorized to update specific CI classes or attributes, preventing data conflicts when multiple sources populate the same CI.
- Rules can be defined at parent or child class level
- Data source precedence determines which source wins
Lower priority number = higher authority (e.g., priority 100 beats 200). This is consistent with official ServiceNow documentation.
Identification Rules vs Reconciliation Rules
| Aspect | Identification Rules | Reconciliation Rules |
|---|---|---|
| Primary Goal | Prevent duplicates | Control updates |
| Focus | Matching criteria | Data source priority |
| Outcome if No Match | Create new CI | Block or allow update |
Reconciliation prevents "data flipping" in multi-source environments. Configure early. Higher precedence (lower number) = authoritative source.
CI Relationships
CI relationships define connections between CIs, enabling dependency mapping, impact analysis, and service modeling.
Structure: Parent CI → Relationship Type → Child CI
Relationship Types
| Relationship | Example | Category |
|---|---|---|
| Runs on::Runs | Application runs on Server | Hosting |
| Depends on::Used by | Service depends on Application | Logical dependency |
| Contains::Contained by | Rack contains Server | Physical grouping |
| Connects to::Connected by | Server connects to Switch | Network |
| Virtualizes::Virtualized by | Hypervisor virtualizes VM | Virtualization |
Dependent relationships are used by the IRE for identification. Non-dependent relationships are descriptive only.
Best Practices
- Use Suggested Relationships in CI Class Manager
- Create bidirectional relationships for visibility
- Align relationships with CSDM
Naming Conventions and Schema Design
Schema Design
- Extend existing classes minimally
- Follow CSDM domains
- Avoid deep custom hierarchies
CSDM-Aligned Naming
- Use unique, descriptive names
- Application Services format: "<Service Name> - <Environment>" (e.g., "Email - Production")
- Avoid duplicates
- Use business-friendly names
Align schema to CSDM stages (Crawl/Walk/Run/Fly) and validate with the CMDB Health Dashboard.
Good vs Bad Practices
| Area | Good | Bad |
|---|---|---|
| Class Extensions | Minimal / OOTB | Deep custom hierarchies |
| Naming | Unique, descriptive | Generic / duplicates |
| Schema Alignment | CSDM-compliant | Custom silos |
CMDB Health Completeness
Required Fields
Hard enforcement via System Dictionary — a CI cannot be saved without this field populated. Impacts the Completeness score under the "Required" metric.
Recommended Fields
Soft check via CI Class Manager — a CI can be saved without this field, but it reduces the Completeness score under the "Recommended" metric.
Required is global; Recommended is class-specific.
An administrator needs to ensure that all Server CIs display in the Incident CI reference field, but individual Hard Drives and Network Cards should not appear. What should the administrator configure?
Configure the Principal Class filter in the CI Class Manager. Add the Server class (cmdb_ci_server) to the Principal Class list. Do NOT add Hard Drive (cmdb_ci_hard_disk) or Network Card (cmdb_ci_network_adapter) to the list. The Principal Class filter controls which CI classes appear in ITSM reference fields.
An organization wants to ensure that the 'Host Name' field is always populated for Windows Server CIs, and they want CIs missing this field to count against CMDB Health Completeness. How should this be configured?
Set Host Name as a mandatory field in the System Dictionary for the Windows Server class (cmdb_ci_win_server). This makes it a Required attribute. Additionally, in the CI Class Manager under Health > Completeness, verify that Host Name appears as a Required field. Required fields are enforced at save time AND counted in Completeness.
What is the difference between marking a field as 'Required' in the System Dictionary versus 'Recommended' in the CI Class Manager?
Required (System Dictionary): Hard enforcement — the CI cannot be saved without this field populated. Impacts Completeness under 'Required' metric. Recommended (CI Class Manager): Soft check — the CI can be saved without this field, but it reduces the Completeness score under the 'Recommended' metric. Required is global; Recommended is class-specific.
Key Takeaways
- cmdb_ci is the root of all CI classes — subclass tables extend, not replace, parent attributes
- CI Class Manager controls class structure, not CI data — requires sn_cmdb_admin + personalize_dictionary roles
- Principal Class filter controls which CIs appear in ITSM reference fields like Incident CI lookups
- Independent CIs are identified by their own attributes; Dependent CIs require parent identification first
- Identification rules match incoming data to existing CIs; Reconciliation rules control which source can update
- Lower reconciliation priority number = higher authority (100 beats 200)
- Normalization standardizes values (e.g., manufacturer names) using Normalization Data Services (NDS)
- Always extend existing OOTB classes rather than creating new root classes
- Required fields (System Dictionary) enforce at save; Recommended fields (CI Class Manager) affect health scores only
Community-created study aids. Not official ServiceNow exam content.