---
sourceDocument: Yokohama IT Operations Management
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/yokohama/it-operations-management

 Release :

    - yokohama

ft:locale :

    - en-US

ft:publication_title :

    - Yokohama IT Operations Management

ft:clusterId :

    - itom

bundleId :

    - itom

workflow :

    - Technology


---

# Binding alerts to a specific host CI (default binding)

# Binding alerts to a specific host CI (default binding) {#ariaid-title1}

* Release version: Yokohama
* 
* Updated August 11, 2026
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 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 Binding alerts to a specific host CI (default binding)

Binding alerts to Configuration Items (CIs) using the Node or CI Identifier fields in event records ensures precise association of alerts with the correct host CIs.
This accurate binding enhances incident response, root cause analysis, and impact assessment by clearly identifying the affected assets.
Show full answer Show less  

## How Default Binding Works

* The system uses the Node field or CI Identifier field from the event record to bind alerts to host CIs.
* Since CIs do not have a Node field, the Node value from the event is matched against host CI attributes such as Name, Fully Qualified Domain Name (FQDN), IP address, or MAC address.
* If a match is found, the alert is linked to that host CI. Host CIs must be hardware components like Computers, Operating Systems, Switches, Routers, or any class extending the `cmdbcihardware` table.
* The system ignores hosts whose operational status is not included in the `sa.activeoperationstatus` property when binding via IP/MAC using the Node field. By default, only hosts with status "Operational" (value 1) are considered, but this list can be extended to include additional statuses such as Non-operational, Repair in Progress, DR Standby, or Retired.
* If no match is found via Node, the system checks the CI Identifier field, a JSON structure specifying particular column names and values (e.g., serial number) for matching against CIs.

## Difference Between Node and CI Identifier Binding

* Binding via Node attempts to match all fields in the Additional Information field against CIs, while the CI Identifier field allows explicit specification of matching fields through a JSON structure.
* Both binding methods apply only to host CIs.
* Event rules with the "Override default binding" option can modify or override the default alert-to-CI binding based on business logic rather than direct field matches.

## Practical Example

When an event from a server (e.g., Server-123) contains a Node value like "Server-123.example.com," the system compares this value against host CIs' attributes such as FQDN. If a match occurs, the alert links to that CI. However, event rules can dictate alternative bindings, such as linking the alert to a parent CI like a cluster instead of the individual server, ensuring flexible and accurate alert management.  
Binding alerts to Configuration Items (CIs) using the Node field or the CI Identifier field ensures accurate event association. By comparing an event record's
Node or CI Identifier value, alerts are linked to the right system. This improves response, root cause analysis, and impact assessment by providing clear visibility into affected
assets.

## How default binding works {#binding-alert-CI-host-default__section_p3t_zfy_k2c}

The system can perform default binding using the Node field or the CI Identifier field from the event record.

When an event enters the system, a key field like Node is available in the event record. However, there is no Node field in the CI. Instead, the node value from the event is
compared with various attributes 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 method for binding
alerts to CIs.

The property sa.active_operation_status is used by the default binding mechanism, specifically when binding via IP/MAC using the node field in the event. When an event attempts to bind to a host through
the node field (using IP/MAC), the system ignores hosts whose operational status is not included in this property and the operational status of the host must also not be null. By default, the property value is "1", which
corresponds to Operational. You can extend the list to include additional statuses, and any status in the list is not ignored during binding.  
Example: If sa.active_operational_status = "1,2", then both Operational and Non-operational hosts are considered valid for binding. The status attribute is defined by the following values:

* 1 -- Operational
* 2 -- Non-operational
* 3 -- Repair in Progress
* 4 -- DR Standby
* 6 -- Retired
{#binding-alert-CI-host-default__ul_vk3_yc1_lhc}  
Note:  
In this binding process, the CI must be a host. Host CIs include Computers, Operating Systems (OS), Switches, Routers, or any CI type/class that extends the \[cmdb_ci_hardware\] table, meaning the CI type or class must be a hardware component.

If no match is found using node, the system looks at the CI Identifier field on the event record. The CI Identifier is a JSON structure containing column names and values for
comparison (e.g., Name, Fully qualified domain name, IP, or MAC Address). The JSON is: {"column_name":"\<column_value\>"}. For example, if we want to bind to a CI identified by serial_number whose
value is Dell Latitude 7420 Laptop, the JSON is: <kbd class="ph userinput">{"serial_number":"Dell Latitude 7420 Laptop"}</kbd>. If a match is found, the alert is linked to the corresponding CI.

## Difference between binding with Node vs. CI Identifier {#binding-alert-CI-host-default__section_ufn_3p1_l2c}

In default binding, the system considers all fields in the Additional Information field and attempts to match their values with the CI table. The CI Identifier field allows
specifying particular fields for matching, even if they are not present in Additional Information. This process uses a predefined JSON structure and
applies only when the CI is a host.  
Note:  
Even if the Node or the CI Identifier successfully binds the alert with the CI, event rules further determine how the binding occurs using the Override default binding check box available in Event rules. This ensures that alerts are bound correctly based on business logic, not just direct matches. This ensures that alerts are bound correctly based on business logic, not just direct matches.

## Example: Resolving a CI Using Node and Event Rules {#binding-alert-CI-host-default__section_rn5_bgy_k2c}

Imagine a server (Server-123) in your network generates an event. The event record contains a Node field with the value "Server-123.example.com".

1. Matching with CI Attributes:
   1. The system checks the Node value against the CMDB.
   2. It compares "Server-123.example.com" with the FQDN, IP, MAC address, or Name of existing host CIs.
   3. If a match is found (e.g., FQDN in the CMDB is also "Server-123.example.com"), the alert is linked to that CI.
   {#binding-alert-CI-host-default__ol_lfj_1qp_k2c}
2. Applying Event Rules: Even if the Node resolves to Server-123, additional event rules might determine if the alert should be linked differently. For example, an event rule may specify that alerts from Server-123 should be linked to a parent CI (like a cluster) instead of the individual server.
{#binding-alert-CI-host-default__ol_kfj_1qp_k2c}