Targeted reliable notifications are the core of any alerting solution.  Blasting out emails may be good for quantity, but Enterprise Alert focuses on quality, this means notifying the right people at the right time.  We often see monitoring and ticketing solutions creating an incident and then relying on the emailed recipient to not only identify and handle the incident but also to close out the ticket that is raised.  This method has a lot of overhead and we hear time and time again that tickets are not properly closed after an incident has been resolved.

Furthermore, getting the notifications to the appropriate on-call engineer or notifying the responsible team can also be a chore.  It may require multiple workflows to direct the notification to the subject matter expert and that can only be done using the incoming events and triggering on specific conditions.  What if there was an easier way to not only cut down on the number of policies that must be maintained but also dynamically pull in the target destination.  This is where Enterprise Alert comes in.

Creating alert policies from incoming events is something that most EA admins are familiar with.  We receive events from any 3^rd party source in a multitude of ways.  During our customer assessments, we often see multiple policies created with only one condition being changed, that being the destination team that corresponds to the alert condition.  In an effort to reduce the number of policies admins need to create we can use the dynamic parameters from the incoming event to dictate where the notification should be delivered.

Let’s Explore

Here we see a ticket created within ServiceNow.  The alert policy notification text is typically dynamically pulled in to reflect what the issue is without having the EA admin type out a specific message.

But why stop there?  Let’s use the event parameters received from this ticket to automatically route the notification for this policy.  We do this in the Alerting section.  We often see specific teams being targeted here.  This means multiple policies to route the alert.  For example, 1 policy targeting the Security Team and then another policy with the same conditions targeting the Applications team. To simplify this, let’s use the Event Parameter option here and set it to a field that will contain the destination team that exists in Enterprise Alert.

Now when the incoming event comes in, the assignment group set in ServiceNow will automatically apply to the corresponding Team in Enterprise Alert.

This example shows incidents raised in ServiceNow but the same principle applies to any 3^rd party system.  The only requirement here is the event parameter name must match a corresponding Team name in Enterprise Alert.
Optimizing the Alert destination in this way can reduce the number of policies that need to be maintained as well as provides dynamic routing capabilities from a single event.

How can we help you?

Do you need to optimize your alert policies to dynamically assign notification recipients? Let us know at support@derdack.com.