---
sourceDocument: Zurich IT Operations Management
sourceDocumentLink: https://www.servicenow.com/docs/r/zurich/it-operations-management

 Release :

    - zurich

ft:locale :

    - en-US

ft:publication_title :

    - Zurich IT Operations Management

ft:clusterId :

    - itom

bundleId :

    - itom

workflow :

    - Technology


---

# Bind host CIs using CI field matching

# Bind host CIs using CI field matching {#ariaid-title1}

* Release version: Zurich
* 
* Updated August 11, 2026
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 1 minute to read

When CI Field Matching is used and the CI is a host, the Node value from the alert is used for binding. The system compares the Node with attributes like Name, FQDN, IP, or MAC Address in the CMDB to find a match. This
ensures that alerts are correctly linked to the corresponding host CI.

## Before you begin

Role required: evt_mgmt_admin

## About this task

When an event enters the system, key field like Node is available on the event record. The Node field generally
represents the name of the server. In CI there is no field like Node. However, the value of Node from the event is compared with different values in the host CI
such as Name, Fully qualified domain name (FQDN), IP, or MAC Address. If a match is found, the alert is linked to the corresponding CI. This is the default binding of alerts to CIs. In this binding, the CI must be a host.
Host CIs include Computers, OS, Switches, Routers---essentially any CI type or class that extends the \[cmdb_ci_hardware\] table.  
There may be cases where no match is found because the column names in the event record and the table differ for the same item. In such cases, you can manually create an additional key-value pair with a name matching the table column, ensuring the matching process continues successfully. For information on how to create a manual field, see [Bind CIs using CI field and column matching](https://www.servicenow.com/docs/tRbvGoKbZ8jqQsyK~DcW5g "Bind CIs by matching event Additional information fields with CI attributes. If column names differ, manually create an additional key-value pair to align with the CI table, ensuring accurate CI association.").  
Note:  
Even if the node successfully binds the alert with the CI, event rules further determine how the binding occurs.

## Procedure

1. Navigate to AllEvent ManagementRulesEvent Rules.
2. Select New and complete the required fields of the event rule.
3. Select the Binding tab.
4. Select the Override default binding check box.
5. In the Binding type field, select CI field matching.  
6. In the CI type field, select the appropriate type of hardware component (such as a server, router, or storage device) that the CI type represents.  
   The CI type determines the specific CMDB table where the system searches for the matching CI. For example, if the CI type is Network Adapter, the system searches in the \[cmdb_ci_network_adapter\] table.
7. Select Submit.  
   Note:  
   You can also use the Service Operations Workspace to define binding rules. For more information, see [Create Enrich automation](https://www.servicenow.com/docs/O8D7CDGzMzYnqrxh_yFF0A "Alert enrichment involves transforming raw events from monitoring tools into a standard format, aiding automated grouping and response. This includes extracting fields from lengthy alert payloads or composing them into a standardized format. Additionally, you can create tags, which are metadata added to alerts for easier filtering and grouping.").
{#ci-matching-ci-is-host__steps_gcx_l4p_k2c}
**Related tasks**   

* [Bind non-host CIs using CI field matching](https://www.servicenow.com/docs/K58htgC3S5ii8aTj227jvw "If no match is found using the Node field, the system uses the CI identifier field to match alerts with non-host CIs based on attributes like Name, FQDN, IP, or MAC. This ensures accurate alert association, improving visibility, troubleshooting, and root cause analysis for diverse infrastructure components.")

*[\>]: and then