Section 3.3: Multisource CMDB (CMDB 360)

Multisource CMDB (CMDB 360)

1. Overview of Multisource CMDB

The ServiceNow Multisource CMDB (commonly referred to as CMDB 360) is an advanced capability designed to maintain a comprehensive history of data source contributions. In a modern IT enterprise, a single Configuration Item (CI) is frequently discovered and updated by multiple integrations, such as ServiceNow Discovery, Microsoft SCCM, Microsoft Intune, and AWS Config.

While the standard CMDB tables (e.g., cmdb_ci_hardware) only store the single "winning" attribute value (the Golden Record), Multisource CMDB tracks the values proposed by all active discovery sources. This capability provides deep visibility, allowing administrators to audit which source reported which value, analyze data conflicts, and understand how the winning value was selected by the Identification and Reconciliation Engine (IRE).

2. Database Architecture and Key Tables

To store multi-source data without bloating the main CMDB tables, ServiceNow uses a dedicated set of database tables. For the CIS-DF exam, you must understand the roles of these tables:

1. cmdb_multisource_data: The primary table that stores the history of proposed attribute values for each discovery source and CI. It acts as the central data model for CMDB 360 reports.
2. sys_multisource_attribute_value: A detailed table that stores the individual attribute-level values reported by each distinct discovery source. The side-by-side CMDB 360 view on the CI form queries this table.
3. sys_multisource_inst: Stores instances of discovery source runs. It records metadata such as the source name, processing status, target CI sys_id, and the last update timestamp.
4. sys_multisource_raw_payload: Stores the raw, unmodified JSON or XML payload strings received from the external source before the Robust Transform Engine (RTE) processes them. This is an invaluable tool for auditing integration logic and troubleshooting mapping failures.

3. System Properties and Configuration

Multisource CMDB is not active by default. It requires an ITOM Discovery license and must be enabled by setting specific system properties. These can be configured under Configuration > CMDB 360 Properties or directly in the sys_properties table:

• glide.identification_engine.multisource_enabled: The master system property that enables or disables Multisource CMDB tracking globally. It must be set to true to capture data.
• glide.identification_engine.multisource_cmdb_ci_enabled: Enables data collection for all classes derived from the base cmdb_ci table. It defaults to true (taking effect once the master switch is enabled).
• glide.identification_engine.multisource_non_cmdb_ci_enabled: Enables data collection for non-CMDB classes (tables that do not extend cmdb_ci, such as Location or User tables). It defaults to false.

Only users with the admin or cmdb_ms_admin role can modify these properties and manage CMDB 360 settings.

4. Reversion Policies and Recalculation Flow

One of the most critical operational features of CMDB 360 is the Reversion Policy. When multiple sources update a CI, the IRE uses data source precedence rules to determine which value to write to the main CMDB record. However, consider a concrete exam scenario: A Windows Server CI has two active discovery sources, SG-SCCM (assigned precedence priority 100) and ServiceNow Discovery (assigned precedence priority 200). The operating system attribute is updated. Both sources report operating system values. Looking up data source precedence rules, SG-SCCM has a higher priority (lowest priority integer), so its value is written as the Golden Record in the CMDB.

If SG-SCCM later determines that the asset is retired, or if the SCCM discovery record is deleted:

• Without Multisource CMDB: The attribute on the CI becomes empty or stale, as the platform has no record of what other sources previously reported.
• With Multisource CMDB (Reversion Active): When Source A's data is removed, the IRE automatically triggers a reversion policy. It queries the sys_multisource_attribute_value table, identifies the active source with the next-highest priority (ServiceNow Discovery, priority 200), and automatically recalculates and writes its value to the CMDB CI record. This ensures that the CMDB CI is always populated with the highest-priority active data.

5. Scripting and REST API Integrations

For advanced customization and reporting, ServiceNow provides a scriptable API to retrieve multisource data. Implementation specialists can query the store programmatically using:

• SNC.IdentificationEngineScriptableApi.getMultisourceData(String ciSysId): This method returns a JSON-formatted string containing all attributes, reported values, and source metadata for the specified CI.
• REST API Endpoints: External systems can query CMDB 360 records using the standard ServiceNow Table API against cmdb_multisource_data, enabling external audits without impacting transaction logs.

6. Auditing, Querying, and Reporting

CMDB 360 data can be analyzed using several platform interfaces:

• CMDB 360 View: An interactive grid available directly on the CI form. It shows a side-by-side comparison of every attribute value proposed by each discovery source, highlighting the winning value in green.
• CMDB Query Builder: Administrators can create queries that filter CIs based on multisource criteria. For example, you can query for all CIs where SCCM and ServiceNow Discovery report different values for the operating system version.
• CMDB 360 Dashboard: Provides high-level metrics on data source coverage, conflict rates, and completeness across multiple integrations.
• Database Performance & Table Cleanups: Because these tables store history for every discovery source run, they can grow extremely large in high-volume environments. ServiceNow recommends configuring Table Cleanup rules (sys_auto_flush) to purge historical data after a retention period (e.g., 90 days) to prevent database performance degradation.