Some PDIs are currently unavailable, and PDI actions are paused. View the latest updates here. Read More

Option to create new alert when the associated incident is closed

arunmanohar
Giga Contributor

Current Setup

  1. Event creates an Alert.
  2. Alert creates an Incident and Case.
  3. We use the OOB active interval (evt_mgmt.active_interval) of 4 hours.
  4. If the same event reoccurs:
    • After 4 hours a new alert is created.
    • Within 4 hours the existing alert is reopened/updated

Problem Scenario

Time Action
10:01Alert created
10:02Incident and Case created
10:05Agent manually closes the Case and Incident
10:10Same event reoccurs

Since the event reoccurs within the 4-hour active interval, ServiceNow reopens/updates the existing alert.

However, the associated incident is already Closed. In our implementation, closed incidents cannot be moved back to WIP/Open.

As a result:

  • The alert gets updated/reopened.
  • since the incident remains closed - Only a work note is added to the closed incident

Requirement

When an event reoccurs within the active interval, we want the platform to check whether the incident associated with the alert is closed.

If the associated incident is closed, instead of reopening/updating the existing alert, we would like to:

  1. Create a new alert.
  2. Create a new incident and case from that alert.
  3. Continue normal processing for the newly created records.
1 REPLY 1

Vikram Reddy
Tera Guru

Hey @arunmanohar, there's an out of the box property for exactly this: evt_mgmt.alert_reopens_incident.

Event Management Properties > On Alert Reopen
evt_mgmt.alert_reopens_incident = Create New Incident
evt_mgmt.active_interval = 14400

That property is the missing piece in your flow. Right now it's presumably left on the default that just drops a work note on the closed incident. Switch it to Create New Incident and the behavior changes: the alert still reopens as usual when the same message key reoccurs inside the active_interval window (that part is driven purely by message key matching, not by task state), but instead of touching the closed incident, it spins up a new incident off that reopened alert.

The practical effect is what you're actually after: normal downstream processing kicks back in because it's a genuinely new incident record, not a note bolted onto a closed one. Since your case creation presumably fires off incident creation, the new case follows the same path. You don't need custom logic to check the incident's state before deciding whether to reopen or create fresh, the platform already does that check internally, it's just gated behind this one property.

One nuance worth flagging: the alert record itself stays the same reopened alert, not a brand new em_alert row. If your requirement is strictly "a new alert sys_id every time," that's a separate ask handled through correlation rules or a message key tweak, not this property. But if the real pain is closed incidents silently absorbing work notes while nobody works the recurrence, this property alone fixes it.

Worth double checking the exact property label and page location in your version before you flip it, Event Management's property pages have moved around a bit across releases.

 

Thank you,
Vikram Karety
Octigo Solutions INC