**Introduction:**

Event Management in ServiceNow is very powerful, which help organizations to monitor ,analyze and remediate alerts as quickly as possible. This module also helps us to integrate with most of the monitoring solutions like Splunk, Dynatrace, etc. Also we have other ways to collect events like SNMP traps and OOB connectors for SCOM, Nagios, etc. which helps us to have one central system to monitor all alerts from different sources and no need to have multiple screens for multiple source. Specially this helps for NOC, Monitoring teams to have one big Operator Workspace with all alerts and task related to it in one place.

When we integrate with Multiple systems we get many events which are not always alerts or notable events. To reduce noise i.e. alerts we need to process events, filter them and only create alert for events which are of our interest. So in ServiceNow we have a event rules to do this which I will explain in detail with its related components / concepts.

**Please read more about event management and event rules on [ServiceNow Docs](https://docs.servicenow.com/bundle/newyork-it-operations-management/page/product/event-management/task/create-or-edit-event-rule.html#t%5FEMCreateAdvancedRule). This article is my understand and trying to explain it in my own language and support my next articles.**

**Components of Event Rules :**

**Event Rule Info :**

In this section we give name for the event, select the source to which this event rule applies to and the order of execution of the event. Interesting to note one thing is if we have multiple events for same source then the order plays an vital role in deciding which event rule to apply. So if you have two event rules with order 200 and 250 then lowest order rule is applied i.e. 200\. If you have same order for multiple event rules like 100 and 100 then first event rule is applied. To apply more conditions to event rule we use event filter.

**Event Filter:**

This is where you use condition builder to decide if the event rule should ignore the event or proceed with transforming the event into alert or not. See below image there is one check box to decide whether to ignore the event or proceed further. Now in this filter condition we can select all fields on events table. **_Most important is we can right our REGULAR EXPRESSIONS as well_**. So if you have a

**Example:** If you need to process event if the description starts with specific keyword. Then you can create the filter condition as below:

**Transform and Compose Alert Output:**

This is a section where you maps values from event to alert. While this mapping you can build the fields for alerts. Means if you do not have node in node field on event but it is present in description or additional information field then we can fetch that from this fields and map to node field which will be used for CI binding with alert.

For example: Node is not supplied in node field but in description as below:

So to map the extract node value from description we need to create a regular expression as below:

(a : Map the value to node field)

(b: Pull node from right side to node field on left side)

In Transform and compose you can also add manual attributes which gets added to additional information field on alert automatically.

**Threshold :**

Interesting section on event rule which helps use to reduce noise further. Meaning we can give thresholds like if the event occurs multiple times within specified time then only create an alert out of this event.

**Example:** Lets say we want to create a alert only if the event comes 3 times in 2 minutes. Other example can be out of memory example. Lets say we get 90% consumption alert for a server and this 90% threshold is in description then we can fetch that value and compare it in threshold rule. If >= 90% then only create alert.

(Example 1 : With occurrence for 3 times)

(Example 2 : With Memory Usage)

**CI Binding:**

In this section we decide Configuration item on alert. We by default use identification Rules to calculate the CI. OOB identification of CI is done based on Name, FQDN, IP address and Mac Address of the CI on hardware table. We can override the OOB CI identification and write our own identification rules. If we have to map alert to application then we need to create the identification rule as per our expectation and override the default CI binding. _**For this part I have many use cases which I will cover in next article. Keep watching and stay tuned.**_

**Conclusion:**

We learnt about how to use different sections and component in event rules in event management. We saw the benefits and flexibility of the event rules.

Please add your comments and suggestions so I can improve and explain you in detail. I will be covering other concepts as well in next articles. I have added the link below to my video as well.

**Thanks and Regards,**
**Ashutosh Munot**

**[ServiceNow MVP 2019/2020](https://community.servicenow.com/community?id=community%5Fblog&sys%5Fid=fb488720dbaacc504819fb2439961900)**

**[My Article and Blogs](https://community.servicenow.com/community?id=community%5Fuser%5Fprofile&user=2a131665db1c1fc09c9ffb651f9619fb)**

**[YouTube Channel](https://www.youtube.com/channel/UCf7bnvR3MOiJN5tDxLZPNuw?view%5Fas=subscriber)**