Binding alerts to CIs

---
title: Binding alerts to CIs
description: CI binding or linking is the process of finding and connecting a Configuration Item \(CI\) from the Configuration Management Database \(CMDB\) to an alert, using the logic defined in event rules. This helps ensure alerts are tied to the right IT components for better visibility and faster issue resolution.
locale: en-US
canonical_url: https://www.servicenow.com/docs/r/australia/it-operations-management/event-management/ci-binding-alert.html
release: australia
product: Event Management
classification: event-management
topic_type: concept
last_updated: "2026-09-10"
reading_time_minutes: 3
breadcrumb: [Event rules, Processing Events, Configure, Event Management, ITOM AIOps, IT Operations Management]
---

# Binding alerts to CIs

CI binding or linking is the process of finding and connecting a Configuration Item \(CI\) from the Configuration Management Database \(CMDB\) to an alert, using the logic defined in event rules. This helps ensure alerts are tied to the right IT components for better visibility and faster issue resolution.

## Understanding CI binding

Binding alerts to CIs links incoming alerts to the correct CI—such as a computer, server, router, or virtual machine—enabling accurate tracking and faster troubleshooting.

In IT Operations Management, the relationship between alerts and CIs plays a critical role in effectively managing services and infrastructure. A CI represents a component within your IT environment, such as a server, application, or database. Linking alerts to CIs ensures that alerts and incidents are directly associated with the affected component, enabling accurate impact analysis and faster resolution.

In dynamic and large-scale environments, it’s often challenging to pinpoint which CI is responsible for triggering an alert. Alerts are generated from raw event data captured across multiple sources, but this data may not explicitly reference a CI. Without a reliable method to bind alerts to CIs, IT teams face the risk of:

-   Poor visibility into service impact.
-   Longer mean time to resolution \(MTTR\).
-   Inefficient alert management processes.

Event rules provide a structured way to analyze incoming event data, enrich it with additional context, and map it to the correct CI. These rules act as a bridge, transforming raw event data into actionable alerts linked to CIs. For example, event rules can:

-   Parse incoming event data: The process involves breaking down raw event data to extract important details, such as hostnames, IP addresses, or service tags. These details identify the event source, type, and impact, and enrich the alert with context such as affected services, priorities, and resolution steps.
-   Match patterns: Event details—such as hostnames, IP addresses, or service tags—are compared against CMDB entries to identify the corresponding CI. The alert is then linked to the CI, providing context for faster resolution.
-   Bind the CI to the alert: The alert is automatically linked to the identified CI, making it easier to track and resolve.

## Types of CI binding

|Binding type|Description|
|------------|-----------|
|Implicit Node binding \(Default binding\)|Binds alerts to host CIs by matching the **Node** field in the event with attributes like Name, FQDN, IP, or MAC address.|
|CI field matching binding|Binds alerts using the **CI Identifier** field, a JSON structure containing column names and values \(e.g., Name, FQDN, IP, or MAC Address\).|
|CI identification binding|Binds alerts to specific applications on hosts using event rules.|
|Process-level binding|Binds alerts to application CIs by matching process-related attributes.|
|Device-level binding|Binds alerts to device CIs by matching event data with attributes like hostname, IP address, or MAC address.|

## Key benefits

-   Improved service visibility: Alerts linked to CIs provide a clear picture of which IT components are affected.
-   Enhanced automation: Automated CI binding reduces manual effort, ensuring consistency.
-   Faster resolution: Teams can quickly diagnose and resolve issues by focusing on the impacted CI.

## Example use case

Scenario: A company’s email server named MailServer-01 goes down.

Process:

1.  Alert generation: An alert is triggered when MailServer-01 becomes unresponsive.
2.  CI binding: Event Management automatically looks for MailServer-01 in the CMDB \(Configuration Management Database\).
    -   If found, the alert is linked to this specific server \(CI\).
    -   If not found, the alert remains unlinked until more information is provided.

Result: The alert now shows that MailServer-01 is the affected system.

-   Impact: IT teams immediately know which server to investigate.
-   Efficiency: They don't need to check other infrastructure components or systems, saving time and effort.

This direct link helps streamline troubleshooting by pointing to the exact problem source.

To enrich alerts by identifying the CI or extracting, composing, or tagging alert fields, you can also create an enrich automation in Service Operations Workspace. For more information, see [Enrich automation](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-operations-management/event-management/enrich-alert-sow-itom.md).

**Related topics**  


[Simulate event processing](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-operations-management/event-management/simulate-event-processing.md)