A web service endpoint, for instance ServiceNow, may response with useful information to a notificate, like a ticket number. There should be a way to associate that information with the event frame that triggered the notification.

Allow the ability to configure a delay in sending Notifications so that they would only send if the triggering event frame is open for a configurable amount of time.

This is possible at the analysis level using the True For setting; however, this does not allow to track all triggering events with Event Frames but only be notified for events that last for a certain duration.

Add the ability to send one email with multiple notifications inside it. User can get overwhelmed if they're getting a lot of SQC notifications at once, would be nice if it was one email with the various notifications listed.

This would work: Every X minutes the Summary would run and if any new notifications came up it would send them as one email.

Allow Notification subscribers to receive notification based on severity level. For example if start trigger is warning send it to A, B, C emails; if start trigger severity is minor then send it to A-F emails; etc.

It would be very useful if an "outage" for PI Notifications could be scheduled. We often start or finish maintenance well outside of work hours, and the flood of PI Notifications can annoy users who are not on site.
Ideally we could set an outage for PI Notification emails during a set advance time (eg between 5 and 8am on the 19th June 2021).

To update the last send time of the notification to be based on the configured time in the periodic schedule to resend the notification but not the time of the last notification sent.

When configuring a Noification with a REST Delivery Endpoint, there is no way to escape a dot (".") so it doesn't gets interpreted as a path delimiter. There are cases when the dot must be part of the property name. One way to solve it would be to allow escaping it with a backslash or even better (IMHO) to use the JSONPath way to solve this: being able to specify arbitrary property names putting them between brackets and single quotes: ['prop.erty'].

Allow free-form JSON construction. Maybe not replace the simple JSON guide that is the only entry form now, but free-form would allow the kind of flexibility that would empower the user.

This would allow a single template to be used, rather than the workaround to manually override the template for every individual sensor configured, resulting in hundreds of template copies in which only the "Path" field is edited

As a user, I would like to have more customization over the message formats of REST endpoints by being able to use substitution parameters.

There is a requirement to include different information in the email body depending on whether the notification is for the event start or end. Typically, the event start email includes the start time and start values and the event end email also includes the end time, duration, end values and aggregations. The same could be true for other delivery channels.

Currently, the workaround is to create two Notification Rules, one for event start and one for event end, but this is not ideal.

In Design mode, I would like the ability to switch between to the HTML Code of the delivery formats in order to add richer content when I need to.

Notifications should not send a close notification for an event frame that was temporarily closed by the PI Analysis Service.

Allow for additional authentication types to be added for web service delivery endpoints. Currently, the only available options are Windows, Anonymous, and Basic.

There are some cases when the sender wants to modify the format of the SOAP xml itself. Currently Notifications service constructs a XML request including all the variables provided by the wsdl.

The Non-Repetition Interval in Notification Rules is currently only applied to Notifications sent at Event Start. I would like the Non-Repetition Interval to also be applied to Notifications sent at Event End.

We've had issue with Notifications spamming users with events should a PI collective member stop getting data.

At times, we need to disable the notification service until we can resolve the issue. After the issue is resolved, we need to start the notification service, and need an option to have it not send past email notifications.

To be clear, clear all past events on service startup.

For Notifications which send on Event Start and Event End, it would be useful to have the ability to have multiple Message Formats for the same Notification (one to send out at start, one to send out at end).

Advantages:
-Can include "End Time" in only the Notification sent at end (rather than showing an erroneous 1/1/1970 00:00:00 included in the Notification sent at start)
-Can include "Duration" in only the Notification sent at end
-Can fully customize different messages for start and end of the Event Frame