Enabling the Ens.Alert process allows you to route errors to an outbound operation based on the alert itself. We use this to either route alerts to an oncall analyst (and we change the contact information weekly as we rotate amongst our team), or for less critical alerts, we route them to a different email operation that just emails the team as a group. We have rules built around times so we don't get overnight pages for those less critical components based on their existence in a table, while still being able to receive those that are critical at any time. Example: We have scheduling interfaces that alert over holidays because there's no traffic from the business office, so we have a "holiday" table that we maintain yearly for workdays that are holidays (and additional mandatory PTO days) as well as a NoHolidayAlerts table, where we add either the service or the operation to that table that we don't want to receive alerts for. Then those alerts are suppressed on those days for those components. We also have a NoAfterHours table, as well as a NoAfterHoursNoSS (saturday/sunday) table, for those components that we don't want to hear from if it's not business hours M-F. Let me know if you need more info! We have quite a number of rules in our Ens.Alert router for these types of things.
We use something like this in our alert rules for a specific set of interfaces. We are using CurrentDateTime, but we found that those are treated like a String value and not a date/time value. Hope this helps you out! Let me know if you have more questions.



Patty - just an FYI but I also had the same issue with ConvertDateTime by itself, and also had to use the extract function with it. Not sure why it doesn't seem to work by itself but thanks for the response with the working answer - I appreciate it!