AX2017

Controlling the frequency of alert notifications

When setting up alerts, it is important to consider how often you want a user to be notified about a particular condition.

The primary determiner of alert frequency is, of course, how often the alerts are processed. If a particular file is processed for alerts just once per month, then at most users can receive this alert once per month. However, processing frequency is only part of the equation—you also need to consider whether a user may have already been alerted about a particular condition, and whether they should be alerted again at this particular processing interval.

Imagine a scenario where a file is processed for alerts once per day or even per hour. For example, users may be actively working on budgets, and you have certain alert conditions that you want to monitor for the budget data. Because users may be saving their budgets throughout the day and changing the budget data, the alerts need to be processed frequently. So imagine that an alert condition resolves to True when this file is processed at 2:00 AM on Monday. Do you want users to receive the same alert again if this condition is still True when the file is processed again the next day, or the next hour?

The answer may vary depending on the type of conditions you are monitoring with alerts, and your alerting preferences. You may want users to be constantly alerted until they correct the issue, even that means they are receiving an alert daily or even hourly. On the other hand, you might prefer that users be alerted of a particular condition once per week at most. In this case you can think of the alerting "interval" as weekly, even though the processing frequency might be daily or hourly.

To control the alerting interval, you can use the alert ID to determine whether an alert is considered "new" or "existing" when it is processed. New alerts will be added to the database and displayed to the designated recipients. Existing alerts will be ignored.

Alert processing is handled as follows:

• When alerts are processed, Axiom Software evaluates all active alert conditions found on the Alert Control Sheet of the file. If a condition evaluates to False, then no action is taken. If the condition evaluates to True, then the alert is eligible for notification.

• Axiom Software then compares all newly eligible alerts to existing alerts in the database, using the alert ID (as defined on the Alert Control Sheet) as the comparison point. If the ID for a newly eligible alert matches the ID for an existing alert in the database, then no action is taken for that alert. If no ID match is found, then the new alert is added to the database and the alert notification is delivered to the designated alert recipients.

• Alerts remain in the Axiom Software database until they are purged using the Scheduler System Data Purge task. This task purges alerts older than a specified number of days (by default, 60 days). It is important to understand that if a user deletes an alert notification from their Notification task pane, this does not delete the associated alert from the database; it simply removes the notification from the task pane.

For example, if you want an alert to be sent every time alerts are processed (assuming the condition evaluates to True), then you could set up the alert ID so that it uses the current date/time stamp as part of the ID (Variance_11202012_0930). If you want the alert to be sent once per month at most, then you could set up the alert ID to use the current month as part of the ID (Variance_June2012).

Keep in mind that the alert ID is compared against all existing alerts in the database, regardless of their source. If another file also has alerts set up with an ID format of Variance_MonthYear, it is possible that an alert ID from one file would match an existing alert ID generated from another file. If this is a concern, then you may want to set up your alert IDs to incorporate the current document ID, so that alerts are unique per document.

Deleting alerts using the System Data Purge task

As discussed above, alerts remain in the system until they are purged by the System Data Purge task in Scheduler. It is important to understand that this functionality is primarily intended as a database management tool to purge old data from the database, and not as a means of alert control.

In theory, if you know that the System Data Purge task is configured to purge all alerts older than 15 days, and you have a file that you want to process for alerts on a monthly basis, then you would not need to worry about making the alert ID dynamic per month because there should not be any alerts left over in the database from the prior month. However, it is best to use the dynamic alert ID method so that you can explicitly control the alerting interval. Keep in mind that the purge task is limited to deleting a specific number of records each time it is run, so depending on how often your purge task is run and how much old data is present in the database, old alerts might not get purged until later than expected.

Also, keep in mind the user experience when configuring the purge task. When alerts are purged from the database, they will disappear from the user's Notification task pane with no explanation (assuming that is how the alerts were delivered). Ideally, the purge time frame should be set so that most users will have already deleted the alert from their task pane by the time the alert record is purged from the database. Setting a shorter time frame may cause user confusion.