CIS - DF Overview

Configuration Management Database

Configuration Item

A record representing a managed component or service.

Base table for configuration items.

A table/type used to classify similar CIs.

A field that stores information about a CI.

A defined connection between two CIs.

The named meaning of a CI-to-CI relationship.

The upstream or containing CI in a relationship.

The downstream or contained CI in a relationship.

A relationship showing that one CI relies on another.

Using CI relationships to understand affected services.

The process of controlling and maintaining CI data.

Trusted data for operations, risk, impact, and service visibility.

Confidence that CI data is accurate, complete, current, and governed.

Making CMDB care part of daily processes.

A CI not updated or validated within the expected period.

More than one record represents the same real-world item.

A CI missing expected relationships.

A CI no longer active but retained for history or control.

A CI removed from active operational use for long-term retention.

A CI maintained by people instead of automated discovery.

A CI that cannot be reliably found by automated discovery.

A CI field that automation cannot reliably determine.

The stages a CI passes through from creation to retirement.

15%

Tool for managing CI classes, attributes, and hierarchy.

Class design, table extension, attributes, and hierarchy review.

Bulk CI loading or source reconciliation.

Inheritance structure between CMDB tables/classes.

Higher-level class that provides inherited fields.

More specific class that inherits from a parent class.

Creating a more specific table under an existing class.

A field defined for a CI class.

A field inherited from a parent class.

Creating unnecessary classes that increase complexity.

Using generic classes that hide important differences.

Use the most appropriate existing class before creating a new one.

Create only when existing classes do not fit the requirement.

Choose the class that best represents the real-world item.

Identification and Reconciliation Engine

Identifies existing CIs and controls updates from data sources.

Determines whether incoming data matches an existing CI.

A set of attributes used to identify a CI.

Helps find a matching CI during identification.

Controls which data source can update CI attributes.

Ranking of sources for attribute updates.

Structured incoming CI data processed by IRE.

Multiple sources may create or update the same CIs.

Duplicates, overwrites, and weaker source control.

CMDB view for multisource CI data and analytics.

CMDB capability for viewing data from multiple sources.

Shows which sources contributed CI attribute data.

Workspace view for reviewing multisource CI details.

Visibility into multisource coverage and source behavior.

You need transparency across multiple contributing sources.

Use IRE and reconciliation, not direct table updates.

Review hierarchy and attributes in CI Class Manager.

Use reconciliation rules to control source updates.

Resolve through source precedence and reconciliation rules.

Records lack relevant fields or report incorrectly.

Harder reporting, upgrades, and governance.

Better class structure and attribute consistency.

Confirms that CIs inherit the right fields and behavior.

Should support reporting, governance, and product use.

Field added to a specific class or inherited from parent.

A CI stored in the wrong table/class.

Moving or correcting a CI into the right class.

Incoming CI data cannot match the correct existing record.

A source cannot update a field due to source rules.

Two sources provide different values for the same CI field.

Use CMDB 360 to compare source contributions.

Class design, IRE, and CMDB 360 decisions.

19%

Populating and maintaining CMDB data from sources.

Automated identification of infrastructure and relationships.

Discovers service/application dependency maps.

Integration method for bringing external data into the CMDB.

Agent Client Collector

ServiceNow component that communicates with internal networks.

Guided ETL framework for importing and transforming CMDB data.

Staging table used before transforming imported data.

Maps imported data into target ServiceNow tables.

Transform framework often used with Service Graph Connectors.

Human entry or maintenance of CI data.

Can create duplicates and technical debt if poorly controlled.

Relationships created by discovery, mapping, or connectors.

Relationships created by users when automation cannot determine them.

Use Discovery, Service Mapping, ACC, or connectors when possible.

Choose based on source, data type, frequency, and reliability.

Infrastructure can be scanned or discovered automatically.

You need service/application dependency visibility.

A supported external data source owns useful CI data.

Agent-based endpoint/server data collection is appropriate.

Data cannot be discovered or integrated reliably.

You need controlled transformation into CMDB tables.

Prefer supported configuration over custom table writes.

Future cost caused by fragile or nonstandard implementation choices.

Custom scripts that bypass IRE or supported connectors.

Uses supported APIs, IRE, connectors, and documented patterns.

Assign ownership and maintain through governed processes.

Create and maintain through controlled manual or integration process.

Define owner, required fields, validation, and lifecycle process.

A regulatory or security identifier tracked against a CSDM object.

Attach compliance/security IDs to the proper CSDM records.

Map identifiers to services, applications, or other governed objects.

Financial/procurement/lifecycle record for an owned item.

CI supports operations; asset supports financial/lifecycle management.

Links asset lifecycle with operational configuration data.

Asset and CI records do not represent the same real-world item correctly.

Operational record for a physical technology component.

Financial/procurement record for a physical item.

Keeping CI and asset states aligned where appropriate.

How often an ingestion source updates CMDB data.

Trust level of an ingestion source for specific data.

Preferred source for a specific attribute or record type.

Making incoming values consistent for reporting and governance.

Changing source data into the target CMDB structure.

Connecting source fields to ServiceNow target fields.

Connecting source relationships to CMDB relationship types.

Mapping incoming data to the correct CI class.

Duplicate CIs, inconsistent fields, and unreliable reports.

Records may bypass identification and reconciliation controls.

Send data through IRE so matching and source control apply.

More current data with less manual maintenance.

Higher risk of stale, incomplete, or inconsistent data.

Can prevent devices or attributes from being discovered.

Must reach target networks and data sources.

Prefer a certified connector when it supports the source.

Use only when supported connectors or ETL patterns do not fit.

Define scope, mapping, ownership, schedule, and reconciliation.

Confirm created CIs, updated fields, and relationships are correct.

Choosing the right data population method.

Person or group accountable for maintaining a non-discoverable field.

Stakeholder accountable for security or regulatory identifier accuracy.

Controls how often a data source feeds the CMDB.

How current the CMDB data is relative to reality.

Whether expected CI relationships exist.

Discovery should feed CI data through identification controls.

Connectors should support controlled CMDB population.

35%

Rules, roles, processes, and measures for trusted CMDB data.

Accurate, complete, current, compliant, and useful CI data.

Defined ownership, standards, controls, review, and remediation.

Administers CMDB configuration and data processes.

Maintains standards, models, and data quality practices.

Owns data quality for assigned scope or domain.

Governs configuration management process and CMDB outcomes.

Owns class expectations, fields, lifecycle, and quality.

Designs platform-aligned CMDB architecture.

Owns platform direction, governance, and business alignment.

Builds supported configurations and integrations.

Designs and implements CMDB solutions for customers.

Accountable for correctness of a data area.

Accountable for process use of CMDB data.

Accountable for service definition and service-related data.

Accountable for application-related records and relationships.

Do not make one admin own all business data quality.

Belongs to owners and stewards, not only platform admins.

Capability for measuring CMDB data quality.

Aggregated measure of CMDB quality.

Completeness, correctness, and compliance.

Measures whether expected CI fields are populated.

Measures whether CI data is valid and structurally sound.

Measures whether CIs follow configured audit rules.

Completeness check for mandatory expected fields.

Completeness check for useful but non-mandatory fields.

Correctness check for duplicate CI records.

Correctness check for missing expected relationships.

Correctness check for outdated CI records.

Compliance check against configured CMDB audit rules.

Required, recommended, duplicate, orphan, stale, and audit.

Configured scoring for KPIs and metrics.

Dashboard for monitoring CMDB health and drilldowns.

Turns data quality issues into visible remediation work.

Key Performance Indicator

Critical Success Factor

Reduce duplicate CIs for principal classes.

Defined ownership and regular remediation process.

Confirming CMDB data matches rules and reality.

Confirming CI data meets configured policy/audit expectations.

Check that CI data conforms to governance rules.

Correcting identified CMDB data quality issues.

Person or group responsible for fixing a data issue.

Defined process for assigning, tracking, and resolving issues.

Process of identifying and resolving duplicate CIs.

Guided tool for remediating duplicate CI records.

Duplicate CI records need guided review and cleanup.

Multiple sources identify the same item differently.

Incoming data lacks reliable matching attributes.

Data inserted without identification controls.

Merge, retire, or correct records according to governance.

Improve identifiers, source mapping, and reconciliation.

A CI class selected as important for CMDB health monitoring.

You need focused health checks for important CI classes.

Limits health focus to meaningful classes.

Monitoring too many irrelevant classes.

Workspace for managing and reviewing CMDB data.

Investigate CIs, health, relationships, and remediation context.

Centralized CI and CMDB management experience.

Dashboard for improving foundational CMDB data quality.

Highlights foundational data issues and improvement areas.

Capability for managing CI lifecycle actions through policies.

Automates governed CI lifecycle management.

Defines how a CI lifecycle event should be processed.

Retire or delete stale CIs through a controlled process.

Condition or lifecycle event that starts governed processing.

Automation used by a Data Manager policy.

A change in CI state requiring governed action.

Moving a CI out of active operational use.

Delete only through controlled policy and governance.

Field that represents CI lifecycle or operational state.

Keeping lifecycle fields consistent across related CIs.

Related records show conflicting states.

Validate, update, retire, or archive the CI.

Add valid relationships or correct classification/scope.

Populate missing mandatory governance fields.

Populate helpful fields that improve reporting and operations.

Correct data so it meets configured audit conditions.

A CMDB actively used in incident, change, service, and risk work.

Product and process use of CMDB data.

Ongoing care and improvement of CMDB data.

Cross-functional group that sets CMDB standards and priorities.

Agreed rule for how data should be structured or maintained.

Mapping of data areas to accountable owners.

Responsible, Accountable, Consulted, Informed

Regular review cycle for CMDB quality and remediation.

Change in CMDB quality over time.

Open CMDB data quality issues awaiting correction.

Raising unresolved data issues to accountable owners.

Define required attributes and quality expectations for a class.

Review and correct data quality issues.

Configure CMDB tools, rules, and dashboards.

Ensure process compliance and CMDB operational value.

Keep CMDB design aligned to platform architecture.

Treating CMDB cleanup as a one-time project.

Data quality is measured, owned, and improved continuously.

Opening details behind a score or metric.

Find affected CIs and remediation targets.

Defined condition used to evaluate CMDB data.

Formal validation that data is correct for a scope.

CI data does not meet a configured compliance rule.

The class or CI set being evaluated.

Score level used to judge health performance.

Importance assigned to fixing a data issue.

CI whose accuracy strongly affects operations or services.

Class important enough to monitor as principal.

Health, dashboards, roles, duplicates, Data Manager, and lifecycle.

Fix foundational records before relying on advanced use cases.

Important CI fields are blank.

Duplicates, stale CIs, or bad relationships exist.

CIs fail configured audit rules.

Repeated measurement and remediation of CMDB quality.

Creates dashboards but little actual remediation.

Issues route to people who can fix them.

Can be assessed overall, by class, or by CI.

20%

Better impact, risk, service visibility, and decision-making.

Shows affected CIs and service impact.

Improves risk and impact assessment.

Helps identify recurring CI-related causes.

Connects vulnerable assets to services and owners.

Links technology to services and outcomes.

Plain-language style querying of CMDB data.

Natural Language Query

A user needs easier exploration without building complex filters manually.

Reusable CMDB query for CIs and relationships.

Captures complex relationship logic for reuse.

Query that traverses multiple CI relationships.

All matching CIs and relationships returned by the query.

Missing relationship direction or class scope.

The parent-child orientation used in relationship traversal.

Classes and records included in a query.

Reporting using multisource CMDB data.

A report built for a specific CMDB question or outcome.

Start with the business question and required CI scope.

Visual map of CIs and their relationships.

Map showing dependencies between CIs/services.

A CI or service object shown on a map.

A relationship shown between mapped objects.

Explore service and CI dependencies visually.

Shows upstream and downstream impact paths.

Adding related CIs to the visible map.

Limiting displayed CIs or relationships.

Relationship path showing how one CI affects another.

Starting CI for a map or dependency investigation.

A CI or service that the current CI depends on.

A CI or service that depends on the current CI.

A ServiceNow product using CI data for outcomes.

Uses CIs for incident, change, problem, and impact.

Uses discovery, events, mapping, and operational visibility.

Can connect customer services to supporting technology.

Can use CI/service context for risk and compliance.

Uses asset and CI context for vulnerability and response.

Dashboard for foundational CMDB improvement insights.

Prioritizes foundational data fixes for better outcomes.

Guided approach for interpreting and acting on dashboard findings.

Teams need guidance turning dashboard results into action.

Standardizes response to dashboard-identified issues.

Turns CMDB data into trends, priorities, and actions.

Queries, maps, reports, dashboards, and product outcomes.

Use saved queries when relationship logic must be reused.

Use maps when visual impact paths matter.

Use dashboards when monitoring trends or remediation priorities.

Use reports when stakeholders need structured data views.

Use NLQ for fast exploratory questions.

Knowing which services depend on affected CIs.

Seeing CI state, relationships, and service context.

Using CMDB data to choose safer operational actions.

A map is only useful if relationships are accurate.

A report is only useful if source data is governed.

Scores do not fix data without ownership and remediation.

Missing relationships can hide affected results.

Reports that connect CIs to the services they support.

Reports that include accountable owner information.

Which sources contributed or conflicted on CI data?

Prevents rebuilding the same CMDB logic repeatedly.

Best supported by saved queries or dependency maps.

Stakeholders can act on CMDB data with confidence.

11%

Common Service Data Model

Standard model for aligning services, applications, and technology.

Creates consistent reporting, service context, and product alignment.

CSDM guides how CMDB data should be modeled.

Map data to the correct domain and table.