Ignore Alert Creation for CIs in Maintenance or Decommissioned

[kaiosilva]

Hi, community!

I would like to know if there is a native way in ServiceNow to prevent the creation of alerts for Configuration Items (CIs) that are under maintenance or decommissioned.

If the only solution is to implement a Business Rule to abort the alert creation, what would be the impact on alert processing time and overall system performance?

I appreciate any insights or experiences you can share!

[Selva Arun · Accepted solution]

Hi,

Yes, there’s actually a way to handle this in ServiceNow without relying on a Business Rule. ServiceNow provides an out-of-the-box Script Include called EvtMgmtCustom_PostBind_Create that runs right after the CI is bound but before an alert is created.

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0692596

By default, this script isn’t active, but you can customize it to prevent alert creation for CIs that are under maintenance or decommissioned. Essentially, you’d modify the script to check the CI’s operational status and ignore alerts for specific statuses.

You’ll need to update the EvtMgmtCustom_PostBind_Create script to include logic like this:

(function postBindCreate(event, alert, origEventSysId) {
gs.log('PostBind_Create custom script is active');

var ignore_statuses = ['4', '2', '3']; // Adjust based on your environment’s operational statuses

var ciid = alert.cmdb_ci.toString();
if (JSUtil.notNil(ciid)) {
var ciGr = new GlideRecord('cmdb_ci');
if (ciGr.get(ciid)) {
var operation_status = ciGr.operational_status.toString();
if (ignore_statuses.includes(operation_status)) {
return false; // Skips alert creation
}
}
}

return true; // Proceed with alert creation if status is not ignored
})(event, alert, origEventSysId);

Performance Considerations

Since this runs before an alert is created, it’s actually an efficient approach compared to a Business Rule that aborts an alert after it’s already in process. Just make sure:

• You’re only querying what’s necessary to keep performance smooth.
• The operational_status field is properly indexed in your CMDB.
• You test it in a lower environment before rolling it into production!

This should help prevent unnecessary alerts and keep things running efficiently

If you believe the solution provided has adequately addressed your query, could you please **mark it as 'Helpful'** and **'Accept it as a Solution'**? This will help other community members who might have the same question find the answer more easily.

Thank you for your consideration.

Selva Arun

[ashwini26]

What will be the impact if we create the alerts for Non-operational status CI's and prevent creation of incidents and cases? Would this impact the licensing as the Alerts are getting created?