Discovery identifiers

Release version: Australia

Updated March 24, 2026

4 minutes to read

Summarize

Summarized using AI

Summary of Discovery identifiers

Discovery identifiers in ServiceNow's Discovery module ensure accurate identification of configuration items (CIs) by matching discovered devices to existing CIs in the Configuration Management Database (CMDB). This process prevents duplicate CIs and applies only to the Configuration item type of discovery. Discovery uses identity probes and sensors to collect device-specific data—such as serial numbers, names, and network information—which identifiers then use to find or update matching CIs, or create new ones if necessary. Accurate identification is crucial for reliable asset tracking.

Show full answer Show less

CMDB Identifier Rules and Tables

Identifier rules are predefined sets of attributes linked to specific CI types or tables, guiding how Discovery identifies devices. These rules include attributes like serial number, IP address, MAC address, and names, and reference related tables to cover all attribute occurrences. Key CMDB tables involved are:

Identifier [cmdbidentifier]: Stores identifier rules.
Identifier Entry [cmdbidentifierentry]: Stores attributes for each identifier.

Examples of rules include those for ESX Servers, Hardware, Storage Servers, and WBEM Services. Customers can create custom identifier rules tailored to specific classes or device types, such as Linux servers, using attributes like machine name, IP, and MAC addresses.

Matching Strategy and Customization

For flexible identification, you can create multiple rules for different CI classes with specific attributes. When networks use bonded interfaces sharing IP and MAC addresses, including the name attribute helps differentiate physical interfaces. However, changing adapter names after identification can cause Discovery to lose track of existing CIs, leading to duplicates.

Evaluation Order and Activation

Discovery processes identifiers based on an order value, with lower numbers evaluated first. Custom identifiers should have distinct order values to control when they run relative to default rules. Identifiers can be disabled by deactivating their Active checkbox to prevent them from running.

Handling Duplicates and Properties

You can control how Discovery handles duplicate CIs using system properties like glide.identificationengine.skipduplicates and glide.identificationengine.skipduplicates.threshold. These settings help manage reconciliation and prevent unnecessary CI duplication.

Identifier Version Control and Upgrades

Discovery identifiers are based on the CMDB Identification and Reconciliation framework. For upgrades from versions before Geneva, a system property (glide.discovery.usecmdbidentifiers) must be enabled to switch to the new identifier system. Custom legacy identifiers require manual conversion to the new format to maintain compatibility. When Service Mapping is active, new identifiers are always used regardless of this property.

Configuring Identity Probes and Sensors

Discovery launches identity multi-probes, which consist of simple probes, to collect identification data from devices in a single authentication session. Customers can customize these probes and corresponding multi-sensors to discover CIs not identified by default probes.

Serial Number Management

Serial numbers are critical identifiers and are stored in the Serial Number [cmdbserialnumber] table. Different CI types may have different serial number formats. It is important not to alter serial number syntax (e.g., by adding prefixes) to avoid inaccurate asset tracking.

After Discovery classifies a configuration item (CI), it uses identifiers to determine if the device already exists in the Configuration Management Database (CMDB).

Discovery launches special identity probes that accumulate identification data for each device and feed that data into the identifiers, which determine the action that Discovery must take for each device. Identifiers accurately determine the identity of the device to avoid the creation of duplicate CIs. This identification step only takes place for the Configuration item type of discovery, not for the other types of discovery.

The identity probe in the base Discovery system can be configured to ask the device for information such as its serial numbers, name, and network identification. The results of this scan are processed by an identity sensor, which then passes the results to the identifier. The identifier then attempts to find a matching device in the CMDB. If the identifier finds a matching CI, the identifier either updates that CI or does nothing. If the identifier cannot find a matching CI, it either creates a new CI or does nothing. If Discovery is configured to continue, the identifier launches the exploration probes configured in the classification record to gather additional information about the device. Exploration probes can be multiprobes or simple probes.

Important:

Serial numbers are necessary for accurate asset tracking. If you modified baseline probes, sensors, or patterns, verify that they still discover serial numbers. In addition, do not configure sensors or patterns to modify the serial number syntax, such as adding a custom prefix. Non-standard serial numbers can lead to inaccurate asset tracking.

CMDB identifier tables


Table	Description
Identifier [cmdb_identifier]	Stores all identifier rules.
Identifier Entry [cmdb_identifier_entry]	Stores all the identifier attributes.

Identifier rules

The default Discovery system contains these identifier rules, each of which is associated with a specific CI type (the sys_class_name field on the CI record) or the table in the Applies to field and contains the appropriate attributes for discovering CIs from the specified table. Where necessary to discover all possible occurrences of an attribute, tables from related lists (Search on tables) are included in the rule. For more information, see Create or edit a CI identification rule.

Table 1. CMDB identifier rules
Rule	Applies to table/attributes	Search on table/attributes
ESX Server Rule	ESX Server [cmdb_ci_esx_server]: correlation_id	none
Hardware Rule	Hardware [cmdb_ci_hardware] serial_number serial_number_type name ip_address mac_address	Serial Number [cmdb_serial_number] serial_number serial_number_type Network Adapter [cmdb_ci_network_adapter] ip_address mac_address
Storage Server Rule	Storage Server [cmdb_ci_storage_server] cim_object_path name serial_number serial_number_type mac_address ip_address	Serial Number [cmdb_serial_number] serial_number serial_number_type Network Adapter [cmdb_ci_network_adapter] ip_address mac_address
WBEM Service Rule	WBEM Service [cmdb_ci_wbem_service]: cim_object_path	none

Matching strategy for the hardware rule

The sys_class_name cannot be an attribute for independent rules, such as cmdb_ci_hardware. If your Discovery identification strategy depends on matching a CI with a specific class, you must create a rule for each class you want to use for matching and specify that class in the Applies to field of the Identifier form.

For example, you can create an identifier for a Linux server with different attributes than the Hardware Rule. You might want to use the machine name, IP address, and MAC address for identification. This is a solution for networks that use NIC bonding or teaming to increase available bandwidth. Bonded interfaces appear to be the same physical device and share the same IP and MAC addresses. The use of the name attribute allows Discovery to differentiate between the individual interfaces in the bonded channel.

Important:

If you create an identifier with the name attribute, avoid changing adapter names. Discovery will be unable to resolve existing CIs for renamed adapters. Discovery labels the Install Status of that CI as "Absent" and creates another CI.

Your new rule would look like this:

Evaluation order for Discovery identifiers

Custom identifiers must have different Order values than those of the default identifiers. Discovery parses identifiers and attributes in sequence from low order numbers to high. You can create identifiers to run before or after the default identifiers, or mixed in with the identifiers from the base system. To avoid any identifier or rule from running, disable it by clearing the Active check box. The evaluation order for CMDB identifiers is established within each rule and only controls the parsing order of the attributes in that rule.

Figure 2. Evaluation order in CMDB identifier rules

Properties for processing duplicate CIs

You can control how Discovery handles duplicate CIs with properties installed with Identification and Reconciliation. Use the glide.identification_engine.skip_duplicates and glide.identification_engine.skip_duplicates.threshold properties. For more information, see Properties for Identification and Reconciliation.

Properties that control identifier versions

All instances use identifiers from the CMDB Identification and Reconciliation framework. Upgrades from pre-Geneva versions still preserve the legacy identifiers, but you can switch to the new identifiers using a property: glide.discovery.use_cmdb_identifiers. If you upgraded from a pre-Geneva version, you must manually add this property and set it to true to use the new identifiers. If you upgraded from Geneva or later releases, this property is available in the System Properties [sys_properties] table. To preserve functionality in custom legacy identifiers, convert them to the new CMDB identifier rules format before enabling this property. The system does not reconfigure your custom identifiers to the new framework automatically.

Note:

When Service Mapping is active, the new identifiers from the CMDB Identification and Reconciliation framework are always used regardless of the property value.