Introduction

ServiceNow Multisource CMDB addresses one of the most common challenges in enterprise configuration management: multiple systems reporting different values for the same Configuration Item (CI). In a typical enterprise, infrastructure information can arrive from ServiceNow Discovery, Service Graph Connectors, cloud platforms, monitoring tools, vulnerability platforms, endpoint-management products, and other integrations. Without a controlled reconciliation mechanism, these sources can create duplicate CIs or continuously overwrite each other’s attributes.

Modern ServiceNow documentation positions CMDB 360 as the evolution of the legacy Multisource CMDB capability. CMDB 360 retains discovery-source information and proposed values at the CI-attribute level, allowing administrators to understand where values came from, compare competing values, modify reconciliation rules, and recompute CI values.

This article explains how Multisource CMDB works, how it relates to the Identification and Reconciliation Engine (IRE), how to configure it, and how consultants can use it in real enterprise implementations.

Current terminology: Multisource CMDB functionality is now part of CMDB 360 in current ServiceNow releases. The term “Multisource CMDB” remains useful because it describes the underlying multi-source data-management capability.

What Is ServiceNow Multisource CMDB?

A traditional CMDB attempts to maintain a trusted representation of configuration items such as:

• Servers
• Virtual machines
• Databases
• Applications
• Network devices
• Storage systems
• Cloud resources
• Containers
• Business and technical services

The difficulty begins when several systems provide information about the same CI.

For example, suppose a Linux server is represented in the CMDB as:

All three systems may be describing the same server, but the information is not necessarily identical.

The purpose of Multisource CMDB is not simply to choose one source and discard everything else. CMDB 360 retains information from the different discovery sources so administrators can understand the competing values and how the final CMDB value was determined. ServiceNow stores CMDB 360 information in the CMDB MultiSource Data [cmdb_multisource_data] table.

This gives administrators a much better answer to questions such as:

• Which system reported this hostname?
• Why does the CMDB contain this IP address?
• Which source currently supplies the operating-system value?
• Which sources disagree about a CI attribute?
• What would happen if the reconciliation rule changed?
• Can a problematic source be excluded and the CI value recomputed?

Why Multisource CMDB Is Important

A large enterprise rarely has one authoritative discovery system for every type of information.

For example:

• Discovery may be authoritative for infrastructure.
• A cloud connector may know more about cloud resources.
• An endpoint-management platform may contain workstation details.
• A vulnerability platform may provide security-related attributes.
• Application teams may own application metadata.
• Monitoring tools may provide operational information.

The problem is therefore not simply data collection.

The real problem is data ownership and reconciliation.

ServiceNow’s IRE provides the centralized framework for identifying and reconciling incoming CI data. Identification determines whether incoming information belongs to an existing CI, while reconciliation controls which discovery sources can update specific CI attributes.

Multisource CMDB extends this concept by retaining information about the different source values instead of leaving administrators with only the final CMDB value.

Key Components of a Multisource CMDB Architecture

A practical implementation normally contains several layers.

1. Discovery and Data Sources

Data may originate from:

• ServiceNow Discovery
• Service Graph Connectors
• IntegrationHub ETL
• Cloud discovery
• Monitoring platforms
• Endpoint-management systems
• Security tools
• Third-party integrations

ServiceNow describes Service Graph Connectors as a way of integrating external systems into the CMDB while maintaining standardized CMDB data.

2. Data Ingestion

The source data enters ServiceNow through an appropriate ingestion mechanism.

The integration should ideally use mechanisms that participate in IRE processing rather than directly inserting CI records into CMDB tables.

3. Identification

IRE evaluates identification rules to determine whether an incoming record represents:

• An existing CI, or
• A new CI

Strong identification rules are essential because poor identification can result in duplicate CIs.

4. Reconciliation

Once the CI has been identified, reconciliation determines which source can update which attributes.

For example:

This is much better than declaring one source authoritative for every field.

5. CMDB 360 / Multisource Data

CMDB 360 retains the source-level information so administrators can inspect competing values and understand how the CMDB value was established.

Real-World Integration Use Cases

Use Case 1 – Discovery and Cloud Connector

Consider a company running workloads across AWS, Azure, and on-premises data centers.

The organization uses:

• ServiceNow Discovery for on-premises servers
• Cloud integrations for AWS and Azure
• Service Mapping for application relationships

The same application server might be represented by more than one discovery mechanism during migration.

A properly designed identification strategy ensures that the same CI is recognized rather than creating duplicate records.

Reconciliation then determines which source controls attributes such as cloud account, IP address, operating system, or infrastructure metadata.

Use Case 2 – Discovery and Vulnerability Platform

A security platform may identify a server and provide security-related information, while Discovery provides infrastructure details.

For example:

Discovery reports:

• Hostname
• Serial number
• IP address
• Operating system
• CPU
• RAM

Security platform reports:

• Vulnerability status
• Security agent
• Security classification
• Last security scan

The security system should not overwrite infrastructure attributes simply because it reports the same server.

Reconciliation rules can restrict each source to the attributes it is trusted to manage.

Use Case 3 – Multiple Monitoring Platforms

Large organizations sometimes operate multiple monitoring platforms after mergers or technology migrations.

Suppose:

• Monitoring Tool A reports CPU information.
• Monitoring Tool B reports memory information.
• Discovery reports both.

Rather than allowing every source to overwrite every attribute, the organization can define attribute-level ownership.

CMDB 360 then allows administrators to compare the source values and investigate differences.

This becomes especially useful during migration from one monitoring platform to another.

Multisource CMDB vs Traditional Reconciliation

It is important to understand the difference.

Traditional reconciliation can establish a precedence model such as:

Discovery > Connector > Manual

If Discovery reports RHEL 9 and another source reports RHEL 8, the reconciliation rule can allow Discovery to win.

The problem with a simple precedence model is that administrators may not have visibility into the rejected value.

CMDB 360 retains the source information and proposed values, allowing administrators to inspect the alternatives.

Conceptually:

Source A ───────┐
                │
Source B ───────┼──> IRE ──> Reconciliation ──> CMDB CI
                │                    │
Source C ───────┘                    │
                                     ▼
                              CMDB 360 Data
                         Source + Proposed Values

This makes troubleshooting considerably easier.

Prerequisites

Before configuring a Multisource CMDB implementation, review the following areas.

CMDB Foundation

Make sure the organization has:

• A defined CMDB data model
• Correct CI classes
• Appropriate identification rules
• Appropriate reconciliation rules
• Defined discovery sources
• A documented data ownership model

Required ServiceNow Capabilities

Current ServiceNow documentation states that CMDB 360 requires the ITOM Discovery License plugin and that the property glide.identification_engine.multisource_enabled must be enabled.

Depending on the implementation, also verify access to the required CMDB and workspace roles.

ServiceNow documentation identifies roles such as:

• sn_cmdb_user
• cmdb_ms_user
• cmdb_ms_editor
• cmdb_ms_admin

The exact role model should be validated against the release and application components installed in the target instance.

Step-by-Step Multisource CMDB Configuration

Step 1 – Review the Existing CMDB Data Sources

Before enabling anything, document every system currently sending CI information.

Create a simple matrix:

Do not start by creating reconciliation rules randomly.

First understand the ownership of the data.

Step 2 – Verify Identification Rules

Navigate through the CMDB configuration area and review the identification rules for the relevant CI classes.

For example:

All → Configuration → CI Class Manager → Server → Identification Rules

The exact workspace/navigation presentation can vary by release, so validate the available menu in your instance.

For a server, identification might use attributes such as:

• Serial number
• Serial number type
• Hostname
• Other class-specific identifiers

The objective is to ensure that the incoming server is matched to the correct existing CI.

ServiceNow’s current IRE configuration guidance identifies identification rules as a core mechanism for preventing duplicate CIs.

Step 3 – Configure Reconciliation Rules

Navigate to:

All → Configuration → CI Class Manager → Select CI Class → Reconciliation Rules

Create or review the reconciliation rules for the required attributes.

For example:

The actual priorities should reflect the organization’s governance model rather than being copied from another implementation.

Current ServiceNow documentation distinguishes static and dynamic reconciliation rules. Static rules specify which discovery sources are authorized to update attributes and their precedence; if both static and dynamic rules exist for the same CI attribute, the dynamic rule has precedence.

Step 4 – Enable CMDB 360

Navigate to:

All → Configuration → CMDB 360 Properties

Confirm:

glide.identification_engine.multisource_enabled = true

ServiceNow documents this as the property that enables CMDB 360.

CMDB 360 can separately control tracking for CMDB and non-CMDB data through properties such as:

glide.identification_engine.multisource_cmdb_ci_enabled

and

glide.identification_engine.multisource_non_cmdb_ci_enabled

Do not change these properties blindly in production. First confirm the expected data volume, supported classes, and storage implications for your environment.

Step 5 – Review CMDB 360 Data

After data begins flowing, open:

Workspaces → CMDB Workspace → CMDB 360

The CMDB 360 view provides visibility into data coming from different discovery sources. ServiceNow also provides CMDB 360 insights through Service Graph Workspace.

For a specific CI, the CI form can expose CMDB 360 information showing:

• Current CMDB attribute value
• Values reported by discovery sources
• Source information

This is particularly useful when an administrator asks:

“Why does this CI have this value?”

Instead of searching through multiple integrations manually, the administrator can inspect the source-level information.

Step 6 – Validate Reconciliation

Use the Preview Data functionality available with reconciliation rules to review which sources are authorized to update particular attributes and their precedence.

For example:

Operating System
--------------------------------
Discovery       RHEL 9      Allowed
Monitoring      Linux       Not authoritative
Endpoint Tool   RHEL 8      Not authoritative

The objective is not merely to make the rule work.

The objective is to prove that the rule reflects the organization’s actual ownership model.

Testing the Technical Configuration

A controlled test should be performed before enabling the design broadly.

Test Scenario

Assume the CI is:

Server: APP-PROD-01
IP: 10.20.30.40
OS: RHEL 9

Discovery reports:

Operating System = RHEL 9

A second source reports:

Operating System = RHEL 8

Expected Result

If Discovery is authoritative for the operating-system attribute:

1. IRE identifies the existing server.
2. The incoming record is matched to the existing CI.
3. Reconciliation evaluates the OS attribute.
4. Discovery remains the authoritative value.
5. The competing value is retained in CMDB 360 source data where applicable.
6. No duplicate server CI is created.

Validation Checklist

Check:

• CI count before and after ingestion
• CI sys_id
• Identification result
• Discovery source
• Final CMDB value
• Competing source value
• Reconciliation rule
• CMDB 360 data
• Integration logs
• IRE logs where troubleshooting is required

Dynamic Reconciliation in CMDB 360

Static precedence is useful when the organization knows exactly which source should control an attribute.

However, some environments need a more dynamic approach.

Current ServiceNow documentation supports dynamic reconciliation rules as part of CMDB 360. Dynamic reconciliation can be used to determine attribute values using the information retained from multiple discovery sources.

This can be useful when source reliability changes over time.

For example, an organization may migrate from Monitoring Tool A to Monitoring Tool B. Instead of permanently hard-coding the old source as authoritative, administrators can use CMDB 360 information to evaluate the available source data and adjust reconciliation behavior.

This is particularly valuable during:

• Tool migrations
• Cloud migrations
• Data-center consolidation
• Mergers and acquisitions
• Discovery-tool replacements

Troubleshooting Common Multisource CMDB Problems

Problem 1 – Duplicate CIs

Possible causes:

• Weak identification rules
• Missing identifiers
• Incorrect source data
• Different serial-number formats
• Hostname inconsistencies

Approach:

Review the IRE identification result before changing reconciliation rules.

Reconciliation controls attribute ownership; it does not compensate for fundamentally weak CI identification.

Problem 2 – Incorrect Attribute Value

Suppose the CMDB contains:

OS = Windows Server 2019

but Discovery reports:

OS = Windows Server 2022

Check:

1. Which source last updated the attribute?
2. Which reconciliation rule applies?
3. Is the source authorized?
4. Is a dynamic reconciliation rule present?
5. What values are visible in CMDB 360?

Current documentation specifically supports viewing discovery-source values at the attribute level through CMDB 360.

Problem 3 – Source Should No Longer Be Trusted

A third-party discovery system may be decommissioned or become unreliable.

Instead of manually changing hundreds or thousands of CIs, use CMDB 360 capabilities to investigate the source and, where appropriate, exclude its contribution and recompute values under the revised reconciliation model. ServiceNow documents the ability to revert integration from a specific discovery source and recompute CI attribute values.

Problem 4 – No Visibility Into Source Differences

If administrators cannot determine where a value originated, verify that CMDB 360 is correctly enabled and that the appropriate data is being collected.

CMDB 360 stores source/CI information in the cmdb_multisource_data table and provides workspace-based query and reporting capabilities.

Best Practices for Multisource CMDB

1. Define Data Ownership Before Technical Configuration

Do not begin with:

“Which source should have priority?”

Start with:

“Which team or system is responsible for this attribute?”

This produces more maintainable reconciliation rules.

2. Use Attribute-Level Ownership

Avoid making an entire source authoritative for every CI attribute.

Discovery might own infrastructure attributes while another platform owns security metadata.

3. Strengthen Identification Before Reconciliation

If duplicate CIs exist, investigate identification first.

A perfect reconciliation strategy cannot fix a CI that was never correctly identified.

4. Avoid Direct CMDB Inserts

Use supported CMDB ingestion mechanisms that participate in identification and reconciliation.

IntegrationHub ETL, Service Graph Connectors, Discovery, and other supported mechanisms should be selected based on the source and integration architecture. ServiceNow’s integration guidance describes IRE as the framework responsible for centralized identification and reconciliation across supported data-ingestion methods.

5. Monitor Source Quality

Do not assume that a source remains authoritative forever.

Review:

• Missing values
• Conflicting values
• Reporting frequency
• Stale records
• Unexpected source changes
• Discovery failures

CMDB 360 is useful because it allows comparison between discovery sources rather than hiding the rejected values.

6. Use CMDB Health Alongside CMDB 360

CMDB 360 answers questions about source data and reconciliation.

CMDB Health helps assess broader CMDB quality dimensions such as:

• Completeness
• Correctness
• Compliance
• Relationships

These capabilities should be treated as complementary rather than interchangeable.

7. Control Administrative Access

Use appropriate CMDB and Multisource CMDB roles instead of giving every administrator unrestricted access.

Current ServiceNow documentation identifies dedicated Multisource CMDB roles including cmdb_ms_user, cmdb_ms_editor, and cmdb_ms_admin.

FAQ – ServiceNow Multisource CMDB

What is the difference between Multisource CMDB and CMDB 360?

Multisource CMDB is the earlier terminology for managing CMDB data from multiple discovery sources. In current ServiceNow releases, this functionality is incorporated into CMDB 360, which adds capabilities such as analytics, queries, source-level visibility, and recomputation of CI values.

Does Multisource CMDB prevent duplicate CIs?

Not by itself. CI identification is primarily handled by the Identification and Reconciliation Engine. Strong identification rules determine whether incoming data matches an existing CI or represents a new CI. Reconciliation then controls which sources can update attributes.

Can I see values reported by different discovery sources?

Yes. CMDB 360 retains discovery-source information and proposed attribute values. In the CI experience, administrators can inspect the current CMDB value alongside values reported by discovery sources.

Summary

ServiceNow Multisource CMDB solves a fundamental enterprise CMDB problem: different systems can report different information about the same configuration item.

The technical foundation consists of:

1. Reliable CI identification
2. Controlled reconciliation
3. Clearly defined data ownership
4. Multiple supported data-ingestion mechanisms
5. CMDB 360 source-level visibility
6. Continuous CMDB quality monitoring

The most important implementation lesson is that Multisource CMDB should not be treated as simply a feature that selects a winning data source. A successful implementation starts with a well-designed CMDB model and a clear understanding of which system owns which attribute.

Current ServiceNow terminology places the legacy Multisource CMDB capability within CMDB 360, which provides additional analytics, queries, source-level visibility, and recomputation capabilities.

For additional technical details, learners should refer to the official ServiceNow CMDB 360 documentation and the ServiceNow IRE configuration documentation. These should be checked against the release and patch level of the target ServiceNow instance before implementing production changes.