---
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


---

# Overriding default binding

# Overriding default binding {#ariaid-title1}

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

Overriding default binding allows flexibility in linking alerts to CIs beyond the default Node-based matching. This helps customize alert binding based on business needs, ensuring accurate associations and preventing
mislinked alerts, improving incident management and root cause analysis.

By default, alerts are bound to CIs by matching the node value in the alert with attributes like Name, FQDN, IP, or MAC Address in the CI. However, if you want to change this behavior---either by using additional criteria or
ignoring the node altogether---you can use the Override Default Binding check box.  
This allows for two scenarios:

1. When Binding Type = CI Field Matching
   * If the CI is a host, the Node is required for binding. For more information, see [Bind host CIs using CI field matching](https://www.servicenow.com/docs/7Mo~pR7yjjEnCCkE5sPXoA "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.").
   * If the CI is not a host, the Node must be empty. For more information, see [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.").
   {#overriding-default-binding__ul_pfb_htp_k2c}
2. When Binding Type = CI Identification. For more information, see [Bind alerts to CIs using CI identification](https://www.servicenow.com/docs/k9TaJKdQ7Xb9hG6FpElXzw "Bind alerts to specific applications on hosts using event rules to ensure accurate tracking and to improve issue resolution speed—leading to efficient remediation and better alignment of alerts with the right resources.").
{#overriding-default-binding__ol_y5p_qsp_k2c} This flexibility ensures alerts are linked correctly based on specific business needs.  
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.").

