---
sourceDocument: Xanadu IT Operations Management
sourceDocumentLink: https://www.servicenow.com/docs/r/xanadu/it-operations-management

 Release :

    - xanadu

ft:locale :

    - en-US

ft:publication_title :

    - Xanadu IT Operations Management

ft:clusterId :

    - itom

bundleId :

    - itom

workflow :

    - Technology


---

# Alert binding to CIs with event rules

# Alert binding to CIs with event rules {#ariaid-title1}

* Release version: Xanadu
* 
* Updated August 1, 2024
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read

When alerts are associated with CIs, the task of remediation is
simplified. During alert generation, Event Management uses event rules and other mechanisms to automatically bind alerts to a CI
information from the CMDB. For tracking purposes and remediation, the alert shows information about the CI that caused the event.

## Alert binding process flow

Alerts bind to CIs based on the following process flow:

1. When an event arrives, Event Management checks the node or CI identifiers.
2. If no node exists, the generated alert can bind to the CI using the alert Type, Additional information, or Configuration item identifier fields.
3. If the event has a node value, search for a valid host.
4. If the event has a host and a CI type, try to bind to a device CI.
5. If the event has a host, try to bind to the application CI.

Figure 1. How alerts bind to CIs

The event can contain the binding process flow in its Processing Notes field.

By default, events do not bind to CIs with a specified status, such as Retired. To enable binding events to these CIs, set the evt_mgmt.ignore_retired_cis_in_binding property to
false.

To specify the CI statuses to be included in the evt_mgmt.ignore_retired_cis_in_binding property, add the relevant status numbers to the evt_mgmt.install_status_list_to_ignore_in_binding
property, as per the following table:
{#r_EMHowAlertsBindCI__table_e1x_hhl_pjb__entry__2}

| Status Number | Status |
|:-:|:-:|
| 1 | Installed |
| 2 | OnOrder |
| 3 | InMaintenance |
| 4 | PendingInstall |
| 5 | PendingRepair |
| 6 | InStock |
| 7 | Retired |
| 8 | Stolen |
| 100 | Absent |
[Table 1. CI Statuses]

{#r_EMHowAlertsBindCI__table_e1x_hhl_pjb}  
Note:  
When adding more than one status, separate each status number with a comma.

## Tracking and remediation {#r_EMHowAlertsBindCI__section_fzg_t44_ccb}

Alerts can be bound to CIs from the CMDB for tracking purposes and remediation. Event Management uses event rules and various mechanisms to automatically bind CIs to alerts. When information from an event populates a field with a value, the value either originates from the event source or from event rules. This enhances remediation, functionality, and integration with other ITOM products.

## Binding to an application running on a specific host {#r_EMHowAlertsBindCI__section_vmc_dp4_ccb}

If the event is specific to an application type, use the following steps to bind alerts to a specific application:

1. Use the procedures in the [Bind alerts to a CI running on a host using CI identifiers](https://www.servicenow.com/docs/TGV1kRz1E_oElCI0PR~iXg "Create an event rule to bind alerts to a CI running on a host.") topic.
2. Create an event rule with a filter that captures events on the application type you want.
3. In the event rule, select Binding.
4. Click Override default binding.
5. In the Binding Type field, select either CI's Identification or CI field matching.
   1. For CI's Identification, specify the Class.
   2. In the Criterion attributes field, specify <kbd class="ph userinput">name and sys_class_name</kbd>.

   3. In the Name Add Value field, specify the required name.
   4. In the Container level 1 area, specify the required values.
   5. If further container level fields appear, specify the required values.
   {#r_EMHowAlertsBindCI__ol_ac3_gmd_1kb}

{#r_EMHowAlertsBindCI__ol_q43_vld_1kb}

* For CI field matching, specify the required CI Type.
* In the binding process, after the host is found, the algorithm matches all additional_info attributes that have the same name as CI fields for that CI type. If the match is successful, the event is bound to the CI.
* If more than one matching application is found on the host, the alert is bound to the host and not to the application.
{#r_EMHowAlertsBindCI__ul_wmc_dp4_ccb}  
Where there is no CI Type, for example, when binding alerts to an SQL server application when the CPU on sqlServer.exe is over 90%, do the following:

* Populate the Node field in the event with the CI name, FQDN, IP, or MAC address value. The bind is successful even if the host has more than one IP address or MAC address.
* If you want to use a unique identifier that is not one of those previously mentioned, populate the event rule CI Identifier (ci_identifier) field with one or more unique identifiers of the CI. This field should be in JSON format. For example, to use a unique identifier that is not one of those previously mentioned, add a CI Identifier (ci_identifier) filter field with one or more unique identifiers of the CI. If the host CI is VMWare VM, and it has a field called MOID, use the JSON format and specify: <kbd class="ph userinput">{"moid":"&lt;CI moid&gt;"}</kbd>
* Create an event rule with an event match field which maps the process name to the mapping variable <var class="keyword varname">sa_process_name</var>. In this case, do not use the CI type.
{#r_EMHowAlertsBindCI__ul_orn_315_ccb}

## Binding procedures {#r_EMHowAlertsBindCI__section_llf_tb5_ccb}

Use the procedures in these topics to bind alerts.
* **[Bind alerts to a CI running on a host using CI identifiers](https://www.servicenow.com/docs/TGV1kRz1E_oElCI0PR~iXg)**   
  Create an event rule to bind alerts to a CI running on a host.
* **[Bind alerts to a specific host CI](https://www.servicenow.com/docs/JckTty9GtltNPoom0_x97w)**   
  Create an event rule to bind alerts to the correct device CI. An incoming event from a device CI can bind to an alert based on event rule transform information. However, first identify the host CI that the device is running on.
* **[Bind alerts to non-host CIs](https://www.servicenow.com/docs/hc0flKbC1ZCyc5BjQfkT7Q)**   
  Bind an incoming event from a discovered application services or alert group to an alert, based on an event rule and the corresponding event field mapping. The event field mapping requires a URL or the port number and corresponding IP address for each service or alert group.
* **[Bind alerts to application CIs](https://www.servicenow.com/docs/OXdjvAuHRif9emL2tzVLjw)**   
  Create an event rule to bind alerts to the host CI and also to the application CI. An incoming event from an application CI can bind to an alert based on event rule transform information.
* **[Bind alerts to CIs using event field mapping](https://www.servicenow.com/docs/81tvXyCRjrVUSoKsFOTDAA)**   
  Instead of creating separate event rules for each CI you want to bind to an alert, you can use event field mapping to bind an alert to multiple event CIs.
* **[Trigger alert binding to a CI](https://www.servicenow.com/docs/GC~s874e7OslQabgIaMerg)**   
  Trigger a new alert to manually bind an alert to a CI.

**Related concepts**   

* [Event field format for event collection](https://www.servicenow.com/docs/U9fRTAtMX5BKLWST1ZSk9g "Event Management requires all events to use a standard form, regardless of how they arrive at the instance.")