--- sourceDocument: Brazil IT Operations Management sourceDocumentLink: https://www.servicenow.com/docs/r/it-operations-management Release : - brazil ft:locale : - en-US ft:publication_title : - Brazil IT Operations Management ft:clusterId : - itom bundleId : - itom workflow : - Technology --- # Discovery identifiers # Discovery identifiers {#ariaid-title1} Release version: Brazil Updated September 10, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete. ## Summary of Discovery identifiers Discovery identifiers in ServiceNow are used after Discovery classifies a configuration item (CI) to accurately determine if the device already exists in the Configuration Management Database (CMDB). This process prevents duplicate CIs by using identity probes that collect identification data, which is then processed by sensors and identifiers. This identification step applies only to Discovery for the Configuration item type and not to other discovery types. Show full answer Show less The identity probes gather information such as serial numbers, device names, and network identifiers. The identifier then attempts to find a matching CI in the CMDB to decide whether to update, create, or ignore the device record. If configured, Discovery continues with exploration probes to collect further device details. ## Key Features * **Identity Probes and Sensors:** Multi-probes run commands to collect accurate device data, processed by multi-sensors for identification. * **Identifier Rules:** Rules define attributes for matching CIs, tailored by CI type (e.g., Hardware, ESX Server, Storage Server). These rules govern how Discovery matches devices using attributes like serial number, IP address, MAC address, and device name. * **Custom Identifiers and Evaluation Order:** Customers can create custom identifier rules with specific attributes and control their evaluation order to run before or after default identifiers. This flexibility supports complex environments such as bonded network interfaces. * **Duplicate CI Management:** Properties such as *glide.identificationengine.skipduplicates* allow control over how Discovery handles duplicate CIs, helping maintain CMDB integrity. * **Identifier Versions and Compatibility:** The system uses identifiers from the CMDB Identification and Reconciliation framework. Upgrades from older versions require enabling a property (*glide.discovery.usecmdbidentifiers*) to switch to the new framework, and custom legacy identifiers must be converted accordingly. * **Serial Number Tracking:** Serial numbers are crucial for accurate asset tracking and are stored in the Serial Number \[cmdbserialnumber\] table, with proper handling to avoid syntax modifications that could affect tracking accuracy. ## Practical Guidance for ServiceNow Customers * Ensure identity probes are correctly configured to collect serial numbers and other key identifiers to avoid duplicate CIs and maintain accurate asset tracking. * Customize identifier rules as needed for specific CI classes to improve identification accuracy, especially in complex network environments. * Maintain consistent device naming conventions when using identifiers that rely on device names to prevent unintended CI duplication. * Use the provided properties to control how Discovery handles duplicate CIs based on your organization's reconciliation needs. * After upgrading from pre-Geneva versions, add or verify the property to use the modern CMDB identifier framework and convert any custom identifiers to ensure compatibility. * Do not alter serial number syntax in sensors or patterns to preserve the reliability of 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. The identifiers 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.{#c_DiscoveryIdentifiers__identifier-intro} 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 {#c_DiscoveryIdentifiers__section_ayh_nt2_fcb} {#c_DiscoveryIdentifiers__table_j3j_z4l_lt__entry__2} | Table | Description | |-|-| | Identifier \[cmdb_identifier\] | Stores all identifier rules. | | Identifier Entry \[cmdb_identifier_entry\] | Stores all the identifier attributes. | [ ] {#c_DiscoveryIdentifiers__table_j3j_z4l_lt} ## Identifier rules {#c_DiscoveryIdentifiers__section_dkh_pt2_fcb} The default Discovery system contains these identifier rules. Each rule 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 that table. Where necessary, tables from related lists (Search on tables) are included in the rule. For more information, see [Create or edit a CI identification rule](https://www.servicenow.com/docs/access?context=t_CreateCIIdentificationRule&version=brazil&pubname=brazil-servicenow-platform&ft:locale=en-US). {#c_DiscoveryIdentifiers__table_r2p_1ql_lt__entry__3} | 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 {#c_DiscoveryIdentifiers__ul_q3s_2xl_lt} | * Serial Number \[cmdb_serial_number\] * serial_number * serial_number_type {#c_DiscoveryIdentifiers__ul_hpq_rts_lt} * Network Adapter \[cmdb_ci_network_adapter\] * ip_address * mac_address {#c_DiscoveryIdentifiers__ul_i5g_xts_lt} {#c_DiscoveryIdentifiers__ul_v55_mts_lt} | | Storage Server Rule | Storage Server \[cmdb_ci_storage_server\] * cim_object_path * name * serial_number * serial_number_type * mac_address * ip_address {#c_DiscoveryIdentifiers__ul_vf1_l5s_lt} | * Serial Number \[cmdb_serial_number\] * serial_number * serial_number_type {#c_DiscoveryIdentifiers__ul_t1y_p5s_lt} * Network Adapter \[cmdb_ci_network_adapter\] * ip_address * mac_address {#c_DiscoveryIdentifiers__ul_x1y_p5s_lt} {#c_DiscoveryIdentifiers__ul_h1y_p5s_lt} | | WBEM Service Rule | WBEM Service \[cmdb_ci_wbem_service\]: cim_object_path | none | [Table 1. CMDB identifier rules] {#c_DiscoveryIdentifiers__table_r2p_1ql_lt} ## Matching strategy for the hardware rule {#c_DiscoveryIdentifiers__section_i4t_st2_fcb} 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, create a rule for each class you want to use for matching. 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:Figure 1. Linux identifier rule ## Evaluation order for Discovery identifiers {#c_DiscoveryIdentifiers__section_ldy_jv2_fcb} 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](https://www.servicenow.com/docs/access?context=properties-id-reconciliation&version=brazil&pubname=brazil-servicenow-platform&ft:locale=en-US). ## Properties that control identifier versions {#c_DiscoveryIdentifiers__section_cwq_yt2_fcb} 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. * **[How Discovery identifiers work](https://www.servicenow.com/docs/zzGCOPUZcnP4uebRvsmaDA)** When Discovery has determined the device's class, it launches an identity probe that is configured to run one or more commands with a single authentication. * **[Configure Discovery identity probes](https://www.servicenow.com/docs/sJ_ZzxIW7gscmIkQM1vhkg)** Identity probes are multi-probes, which contain one or more simple probes configured to extract specific information from manageable devices. You can create your own identity multi-probe to identify CIs that Discovery does not already identify. * **[Configure Discovery identity sensors](https://www.servicenow.com/docs/XG81vG_OJYNHWtJiRSQ3lg)** If you customize an identify multi-probe, you can also configure a multi-sensor for it. * **[Serial number types for identification](https://www.servicenow.com/docs/phcdu4PE1GF4szJf~NQabg)** As Discovery finds CIs, their serial numbers are listed in the Serial Number \[cmdb_serial_number\] table so they are easy to identify. Serial number types vary depending on the CI, as described in the following examples.