--- sourceDocument: Australia IT Operations Management sourceDocumentLink: https://www.servicenow.com/docs/r/australia/it-operations-management Release : - australia ft:locale : - en-US ft:publication_title : - Australia 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: Australia Updated November 5, 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 Binding alerts to a specific host CI (default binding) Binding alerts to Configuration Items (CIs) via the Node or CI Identifier fields ensures precise event-to-CI association in ServiceNow. This improves incident response, root cause analysis, and impact assessment by accurately linking alerts to the affected host hardware CIs such as computers, OS, switches, or routers. Show full answer Show less ## How Default Binding Works * The system uses the Node value from the event record and compares it with attributes of host CIs (Name, FQDN, IP, MAC address) to find a match and bind the alert. * Binding considers only hosts with operational statuses defined in the **sa.activeoperationalstatus** property (default "1" for Operational), but this list can be customized. * If no match is found via Node, the system checks the **CI Identifier** field, a JSON structure specifying fields and values for targeted matching against host CIs. * The binding process applies exclusively to host CIs extending the **cmdbcihardware** table. ## Distinctions and Event Rule Influence * Node binding matches fields found in event Additional Information, while CI Identifier allows specifying exact fields even if not in Additional Information. * Event rules can override default binding through the "Override default binding" option to enforce business logic, such as linking alerts to parent CIs instead of individual hosts. ## Fallback CI Binding Fields When standard binding methods fail, ServiceNow evaluates these Additional Info fields to bind alerts: * **snfallbackbindingciid**: Direct CI sysid for binding. * **snfallbackbindingciname**: Name of the CI to bind; if duplicates exist, the first match is used. * **snfallbackbindingcitype**: CI class/type to narrow down searches when using snfallbackbindingciname. These fallback keys must be stored in the event's Additional Info JSON and are only used after all standard binding attempts fail. ## Practical Benefits for ServiceNow Customers * Ensures alerts are consistently and accurately bound to the correct host hardware CI, improving event correlation and operational visibility. * Supports customization of binding criteria through operational status settings and event rule overrides for alignment with business processes. * Enables fallback mechanisms to handle edge cases where standard binding cannot find a match, reducing orphaned alerts. * Integrates with Service Operations Workspace for enhanced alert binding and automation capabilities. 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 sa.active_operation_status property controls IP/MAC binding via the node field. The system ignores hosts whose operational status is not in this property or is null. The default value is "1" (Operational). You can add statuses to the list; any status in the list is considered 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":"\"}. For example, if we want to bind to a CI identified by serial_number whose value is Dell Latitude 7420 Laptop, the JSON is: {"serial_number":"Dell Latitude 7420 Laptop"}. 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} Note: You can also use Service Operations Workspace to bind alerts. For more information, see [Enrich automation](https://www.servicenow.com/docs/4GImRp4FbaV8sSboo7rJ7Q "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."). ## Fallback CI binding fields {#binding-alert-CI-host-default__section_qkb_kcc_qjc} Use these Additional Info fields to help the system bind alerts to the correct Configuration Item (CI) when standard CI binding methods don't find a match. * sn_fallback_binding_ci_id: Specifies the exact CI to bind to by providing the CI's `sys_id` * sn_fallback_binding_ci_name: Specifies the name of the CI to search for and bind to. If multiple CIs have the same name, the system uses the first matching CI. * sn_fallback_binding_ci_type: Used in conjunction with `sn_fallback_binding_ci_name`: Use this field together with sn_fallback_binding_ci_name to narrow the search when multiple CIs share the same name. This field specifies the CI class or type that the system should match. {#binding-alert-CI-host-default__ul_tz4_4cc_qjc} The system evaluates these fallback fields only after it attempts all standard CI binding strategies and finds no matching CI. Store these fields (keys) in the Additional Info field of an event and populate them with relevant CI information. When standard binding methods fail, the system uses the values of these fields as fallback criteria for CI binding. For example, the Additional Info field might contain: `{"sn_fallback_binding_ci_name": "linux01"}` In this example, the system uses the value of `sn_fallback_binding_ci_name` (`linux01`) to find and bind the appropriate CI when standard CI binding strategies don't identify a match.