--- sourceDocument: Brazil IT Operations Management sourceDocumentLink: https://www.servicenow.com/docs/r/it-operations-management Release : - brazil ft:locale : - en-US ft:publication_title : - Brazil IT Operations Management ft:clusterId : - itom bundleId : - itom workflow : - Technology --- # Rule-based alert grouping # Rule-based alert grouping {#ariaid-title1} Release version: Brazil Updated September 10, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 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 Rule-based alert grouping Rule-based alert grouping in ServiceNow is managed through alert correlation rules that enable you to classify alerts as primary or secondary and establish relationships between them. This grouping helps reduce alert noise by focusing on root cause alerts (primary) while grouping related secondary alerts under them. The rules apply only to new alerts or alerts reopening from a closed or flapping state. Show full answer Show less This functionality is visible in the Express List of the Service Operations Workspace (ITOM), allowing you to easily see linked alerts within grouped sets. ## Primary and Secondary Alerts * **Primary alert:** Represents the root cause alert in a group. * **Secondary alert:** Related alerts grouped under the primary alert, typically representing symptoms or effects of the primary issue. Secondary alerts are used to suppress noise by grouping multiple related alerts, so you can focus on the primary alert. ## Interaction and Behavior of Alerts Alert correlation rules define filter conditions to classify alerts as primary or secondary by applying criteria to the Alert \[emalert\] table. Both primary and secondary alerts remain visible, with secondary alerts nested under the primary alert. The property **Keep the secondary alert open even when primary closed** (evtmgmt.rulebasedmanualclosure) controls whether secondary alerts close or remain open when the primary alert is closed: * If set to **No**, closing the primary alert removes the grouping and closes secondary alerts. * If set to **Yes**, closing the primary alert removes the grouping but keeps secondary alerts open as standalone alerts. ## Alert Hierarchy Rules Only one level of secondary alerts is allowed. If a secondary alert itself has secondary alerts, the hierarchy is flattened so all secondary alerts are siblings directly under the primary alert. For example, with multiple correlation rules, the system ensures only one primary alert parent exists for any alert, and applies hierarchical flattening to maintain clarity and avoid multiple parent alerts. ## Creating Alert Correlation Rules To implement rule-based alert grouping, you create alert correlation rules that specify conditions for primary and secondary alerts. The primary alert serves as the root cause, with secondary alerts grouped below it to streamline alert management and reduce noise. Rule-based alert grouping is created by alert correlation rules. These rules allow you to manually classify alerts as primary or secondary and establish a relationship between them. Use alert correlation rules to group related alerts. The rule runs only for new alerts or alerts whose status changed from close/flapping to open/reopen. Example: If rule-based alert grouping is applied, secondary alerts indicating that virtual machines or applications on the offline server are also down and are grouped under the primary alert, which is the root alert for the server that is offline. You can view rule-based alert grouping in Express List of Service Operations Workspace (ITOM). For more information, see [Viewing links between alerts in rules-based alert groups](https://www.servicenow.com/docs/P_atJkvfzIynnNsBuRf1nQ "View the connections between alerts in a rules-based alert group in Express List by using Link View. Link View shows how the attributes of the alerts in the group are linked with each other."). ## Primary and secondary alerts * Primary alert: Identifies the root cause of an alert group and represents its secondary alerts. * Secondary alert: Related to the same issue, they are grouped under the primary alert. The purpose of secondary alerts is to determine which alerts to suppress, reducing alert noise and allowing you to focus on the primary alert. {#c_EMEventCorrelationRules__ul_eq3_g3g_s5} ## How primary and secondary alerts interact In rule-based alert grouping, one of the real alerts is designated as the primary alert. Primary and secondary alert filter conditions specify which alerts are classified as primary and which as secondary. The filter criteria are applied to the Alert \[em_alert\] table. In this alert grouping, both primary and secondary alerts are visible but secondary alerts are grouped under the primary alert. The property Keep the secondary alert open even when primary closed. for manual or rule based (evt_mgmt.rule_based_manual_closure) controls whether secondary alerts remain open or are closed when the primary alert is closed. If the property is not selected (i.e., set to No), after the primary alert is closed, the parent reference is removed from the secondary alerts (the grouping is dissolved), and the secondary alerts are closed and become stand-alone. If you select the checkbox for the property (i.e., set it to Yes) and the primary alert is closed, the parent reference is removed from the secondary alerts (the grouping is dissolved), causing them to become stand-alone open alerts. ## Alert hierarchy {#c_EMEventCorrelationRules__alert_heirarchy} Only one level of secondary alerts is permitted. In situations where a secondary alert has its own secondary alert, the Event Management application flattens the hierarchy to preserve only two levels. For example, assume alert A is the primary alert and alert B is the secondary alert. If alert C becomes a secondary alert for alert B, the application flattens the hierarchy so that A remains the primary and B and C become sibling secondary alerts, one level below A. As another example, assume that there are three correlation rules that produce the following results: * Rule 1 (with an Order value of 1): B becomes a primary alert for A. * Rule 2 (with an Order value of 2): A becomes a primary alert for C and D. * Rule 3 (with an Order value of 3): E becomes a primary alert for A. {#c_EMEventCorrelationRules__ul_azx_ng1_1v} When alerts B, C, D, and E are triggered, they all appear in the alert list separately because there are no correlations between them. When alert A is triggered: 1. Rule 1 makes A a secondary alert under alert B. 2. Rule 2 makes both C and D secondary alerts under alert A, and the hierarchy is flattened so that A, C, and D become secondary alerts to the primary alert B. 3. Rule 3 is not applied because multiple parents are not allowed---A already has B as its primary. {#c_EMEventCorrelationRules__ol_f31_mk1_1v} Therefore, if all alerts are triggered, only B appears as the primary alert for A, D, and C, while E remains a standalone alert. * **[Create an alert correlation rule](https://www.servicenow.com/docs/TyLFAm5T4l07JZtKetVPvA)** Create an alert correlation rule to designate primary and secondary alerts. The primary alert is identified as the root cause of the alert group and the secondary alerts are grouped under the primary alert.