It would be great to have an option to backfill/recalculate Event Frame analysis without sending notificaiton.

I agree with this wholeheartedly. The current inability to manage the notification portion within the backfill of an event frame analysis leaves room for user error and can, as it did for me today, result in literally hundreds of emails flooding my inbox. Neither myself nor my customers needed to be notified of the open and close of days-old events. I would like to see, at the very least some incremental improvements, such as

-Only notify of still-open events (i.e., wait to send out any notifications and instead first determine if the event frame is closed, instead of the current method of sending out the open notification, then closed notification)

-A flag/message on the backfill dialog letting you know the Notification Rule is running (linked based on the fact that the Notification Rule's trigger is that Analysis)

Include an options to allow the user to chose if notifications should be sent when configuring a manual backfill for event frames.

The description doesn't fit my exact case, but IT pushes regular updates and notifications that shouldn't be sent out (they have already been closed, sometimes weeks or months in the past) are sent out to users near midnight, waking them up to irrelevant events.

Disabling PI Notifications for a single element when event frames are backfilled/recalculated is manageable. However, there are instances when the service is restarted automatically by an update or patch in which this approach is not practical. Duplicate Notifications that result can confusion with users.

I guess you can just turn off the notification rules of those particular Event Frames and then do a backfill. This way Notifications should not not be triggered.

There are currently two situations where event frames may be backfilled/recalculated. 1) Auto-backfill due to service restart - in this case, the various services may have been restarted due to one of many reasons, such as a reboot, or a power outage, crash or similar events. In these instances, the current behavior is that we would auto-backfill up to 3 days and notifications, if configured, will be sent. The 3 days is to account for a long weekend. In this case, would you want notifications to be sent after the auto-backfill? This is technically a backfill. 2) Manual backfill - this is related to this current suggestion. This suggestion indicates that you wouldn't want to send out notifications. Additionally, we're working on auto-recalculation due to Out-of-Order data for a future release. In that case, you may have a value entering the system in an out of order fashion, perhaps it's a manual lab value, that would create an event frame. Would you want a notification sent in this case? Technically this is a backfill/recalculation. Lastly, if we were to provide an option not to send notifications due to a manual backfill/recalculation, would you want this option to be global (applies to all notification rules) or on a per notification rule basis? Or ???

In response to Stephen Kwan, "There are currently two situations where..." Dear Stephen,   1) Difficult question. It might be logical to send notifications for brand new events. I mean, if there were no eventframe before backfill, but the backfill generated a new eventframes, the notification is reasonable for them. I think the biggest issue with auto-backfill is when new event-frames are generated after an AF Server restart or Analysis service restart. In these cases a duplicated notification is sent of every active EvenFrames.   2) Yes, usually we need to make manual backfill due to modifications in templates or calculations.   3)The easiest solution would be if we could turn on/off notification sending during backfilling, where I can select if I want to delete previous data.     We have made a workaround for the issue, and it is working properly. We have separated AF structures for different functionalities, solutions. So we have created a "Notifications Enabled" attribute in the root element of each solutions.  (Non configuration item!)We have also created a global "Global Notifiaction Enabled" attribute in a separated AF root element. (Non configuration item!)Lastly we have created a formula attribute in each structure "Notifications Active" = min("Notifications Enabled", "\Config|Global Notifiaction Enabled"). This attribute is zero if the notifications are turned off globally or they are turned off for the given structure with the aforementioned attributes.We have put a formula reference eventframe attribute "xyz Notifications Active" in each EventFrames, that generate Notification. The reference points to the "Notifications Active" element attribute of the given structure.After these steps we just had to modify the notification rules to check the  "xyz Notifications Active" eventframe attribute;     With this solution we can turn off the notifications for a given structure if we want to make template modifications or manual backfill for a given solution. And our IT department can turn off the notifications globally if they need to restart the whole server.

If you use PI Notifications to send for example daily reports and those reports are missed for more than 3 days, then you effectively have lost the ability to send the reports. You must manually create them using other PI client tools. It seems like when you are manually backfilling analyses that generate the notifications, there should be a simple configuration option to increase/decrease the 72 hour setting or disable sending notifications all together. That would save the extra step of locating and disabling the notifications before you backfill the analyses.

I totally agree with the suggestion : It would be very usefull en prevent notification being sent when the notification service restarts. In my case, the notification is sent to SAP and triggers a work order. It is important to avoid duplicate work orders in SAP.

Would be nice to choose notification behavior when backfilling. In some use case, I would like to send notifications for events that are older than 72 hours.