How to Group Alerts with a Different Correlation Rules Without Reopening Closed Events

[Tetsuya3]

Hello,

I have a question regarding the behavior of Alert Correlation Rules in Event Management.

After grouping alerts with an Alert Correlation Rule, I cleared the event and closed the alert. Later, when I tried to group alerts using a different Alert Correlation Rule, the closed event was reopened, and the alerts were not grouped.

I assume that this is expected behavior because an alert with the same message key is closed, so it gets reopened. However, is the only way to group alerts with a different correlation rule to send the event with a different message key?

Thank you in advance for your support!

Best regards,

Tetsuya

[AJ-TechTrek · Accepted solution]

Hi @Tetsuya3 ,

In Short, Yes- your assumption is correct. A closed alert with the same message key will be reopened. If you want to apply a different correlation rule and group alerts differently, you’ll need to adjust the message key (often via event rule transformation) or enrich the event payload so it’s treated as a new alert.

Why This Happens
* Alert correlation in Event Management is based primarily on the Message Key.
* If a new event arrives with the same Message Key as an existing alert (even if it’s closed), ServiceNow reopens that alert instead of creating or grouping it into a new one.
* This is expected platform behavior → it prevents duplicate alerts for the same underlying issue.
That’s why in your scenario:
* You closed the original alert.
* A new event with the same Message Key came in.
* ServiceNow reopened the old alert instead of grouping it differently.

Options to Achieve Your Goal as per my understanding -
If you want the same resource to be grouped differently (via another correlation rule), you have a few approaches:

1. Use a Different Message Key
* Yes, you’re right: the most direct way is to change the message key if you want the platform to treat the alert as distinct from the original.
* Example: Append additional attributes (like correlation_type, or a unique identifier from the payload) to the message key.
* That way, ServiceNow won’t reopen the old alert, and the new correlation rule can apply.

2. Custom Correlation Rule Logic
* Instead of relying on the message key alone, you can build a correlation rule that also considers additional fields (e.g., severity, description, or custom fields).
* This way, the grouping can differ depending on context.

3. Leverage Event Rules (Pre-Processing)
* Before correlation, transform or enrich the event in an Event Rule to adjust the message key or add metadata (like “correlation scope”).
* This allows the same CI/event source to participate in different correlation groups without reopening the old alert.

4. There is a Event Management properties where OOB 14400 s is set for reopen the alert is if a same message key event is received , Check this.

Active interval (in seconds), within which a new event reopens a closed alert

4. Best Practice Approach
* Message key = unique technical fingerprint of the problem.
* If you expect different correlation behaviors for the same CI or metric, design multiple message key variations (e.g., CI+Metric, CI+Service+Location) depending on use case.

Suggested Solution
* If you want alerts to be regrouped differently after one has already closed → you must use a different message key (otherwise the alert will always reopen).
* Best practice is to define the message key carefully during event rule design, so that it uniquely represents the grouping you want, while still allowing "OK/clear" events to match properly.

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
 

Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025

[SK5555]

Hello @AJ-TechTrek ,
I am your follower , I have a query , I need to avoid multiple incident , So can I do with Alert correlation rules or not ?
as of now I created some rules but all secondary alerts are having incidents  and primary does not have incident and it is group alert 

could you please help me on this 

Thanks 

[AJ-TechTrek]

Hi @SK5555 ,

As per my understanding why this happens
* Alert Correlation Rule is grouping alerts into one Primary (group) alert + related secondary alerts.
* By default, incident creation rules may still trigger on the secondary alerts (depending on your configuration).
* If incident creation runs before correlation or is not restricted to group alerts only, you get multiple incidents.

Best Practice Solution
1. Configure Incident Creation Rule to fire only for Group Alerts
Navigate to: Event Management → Rules → Alert Management Rule
 In your condition, add:
Correlation ID is empty AND Correlation Alert = true
or
Grouped alert = true

(the exact field depends on your version – in latest releases it’s is Primary or Group Alert flag).
* This ensures incidents are created only for the parent/group alert, never for secondaries.

2. Order of Rule Execution
* Make sure correlation rules run first, then incident creation rules.
* In Event Management → Advanced Settings, check:
* Run Correlation Rules before Incident Creation: should be true.

3. Suppression Rules (Optional)
* If you want to fully prevent certain noisy secondaries from even reaching correlation, you can configure Suppression Rules so they don’t generate incidents.
* But typically you just want correlation + single incident on group.

4. Validate in Alert Console
* Trigger test alerts.
* Ensure only the group alert (primary) shows “Incident created”.
* All secondary alerts should have "Correlated into group alert" and no incident number.

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
 

Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025

[SK5555]

Thanks Ajay , but I am unable to see incident creation rule 

If we use tag clustering, it will generate one Virtual Alert, and all related alerts will be grouped under it as secondary alerts. The issue is that when the first alert comes in, an incident is created before the Virtual Alert is generated. Later, when other alerts matching the tag are clustered under the Virtual Alert, those alerts may already have incidents. What I want is only one incident, and it should be created on the Virtual Alert.