Binding alerts to a specific host CI (default binding)

  • Release version: Yokohama
  • Updated June 16, 2026
  • 3 minutes to read
    • Summarize
    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 theNodeorCI Identifierfields ensures accurate event association in ServiceNow. This process links alerts to the correct host CIs, such as computers, operating systems, switches, routers, or any hardware component extending thecmdbcihardwaretable. Accurate binding enhances incident response, root cause analysis, and impact assessment by clearly identifying affected assets.

    Show full answer Show less

    How Default Binding Works

    • The system primarily uses the Node field from an event record to find a matching host CI in the CMDB.
    • Since host CIs do not have a Node field, the Node value from the event is compared against key host CI attributes such as Name, Fully Qualified Domain Name (FQDN), IP address, or MAC address.
    • If a match is found, the alert is automatically linked to the corresponding CI.
    • Binding considers only hosts with operational statuses defined by the sa.activeoperationstatus property, which by default includes only "Operational" (status 1). This property can be extended to include other statuses such as "Non-operational" or "Repair in Progress."
    • If no match is found via Node, the system uses the CI Identifier field, a JSON structure specifying exact column-value pairs (e.g., serialnumber) for matching against host CIs.

    Differences Between Node and CI Identifier Binding

    • Node-based binding matches values broadly across multiple host CI attributes.
    • CI Identifier binding allows precise matching on specific CI attributes defined in a JSON format, even if those attributes are not present in the Additional Information field.
    • Both methods apply only to host CIs (hardware components).

    Role of Event Rules in Binding

    Even after Node or CI Identifier successfully binds an alert to a CI, event rules can override this binding using the Override default binding option. This enables applying business logic to determine the most appropriate CI association, such as linking alerts to a parent CI (e.g., a cluster) instead of an individual host.

    Practical Example

    An event from a server with Node value "Server-123.example.com" is processed:

    • The system matches the Node value to a host CI with the same FQDN.
    • The alert is initially linked to the matched CI.
    • Event rules may further redirect the alert to a related parent CI based on organizational logic.

    This approach ensures alerts are accurately and contextually linked to the correct CIs, improving visibility and operational efficiency in managing IT assets and events.

    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

    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
    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: {"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

    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

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