It would be nice to have the option to select either starttime or endtime of the eventframe as the timestamp for the value that will be written a PI tag using the Outputs at close feature in Event Frames. Currently, it will only write the value with a timestamp of the endtime of the event frame.

Use case:

I have an event frame and I would like to see the average of an attribute value for that duration of that time frame on PI Vision. The expectation is to see a horizontal line indicating the average value throughout the duration of the event frame.

As of now, the average value is written to the underlying PI Point with the timestamp at the end time of the event frame using the Outputs at close feature in Event Frames.
This leads to a sloping trend when you try to visualize the resultant average values. i.e. the trend links the previous average value (calculated from the end of the previous event frame) to the latest event frame output average value.

With the requested option available and combined with the step parameter in the PI tag, we will be able to visualize a straight horizontal line for the average value of the tag for the duration of the event frame for that particular duration.

It should be possible to configure event frames to be acknowledgeable only if a comment/reason code is entered before. we have this requirement sometimes in life science industry, but i can imagine it might be also usefull in other industries (e.g. for saftey relevant events,...).
a configuration on event / event template base is useful as some events might require an comment and others not.

it should also be possible to configure to require an electronic signature before acknowledge the event. this might be in relation with PI Vision feedback

https://feedback.osisoft.com/forums/320517-pi-vision/suggestions/13659522-notification-event-acknowledgement-support-21-cfr

again the configuration if ESIG is needed should be on EF level, as it might be possible also custom applications (e.g. via Web API or AF SDK) might acknowledge event frames and should be prohibited to do this if the acknowledgement is depending on Reason code / comment or Electronic signature.

Enable the ability for end-user to manage custom severity levels for event frames, to allow for better communications across response teams and business unit functions.

Exposing EF severity levels within a PI Notifications messages is very helpful in providing quick context to an issue. However, it can create confusion when those severity levels do not map well to a specific company's internal standard for incident reporting in either the severity level namings or qty of severity levels.

EXAMPLE MAPPING PROBLEM:
Event Frame = None, Information, Warning, Minor, Major, Critical
Cust 1 = Normal, SEV5, SEV4, SEV3, SEV2, SEV1
Cust 2 = Good, Information, Warning, Major, Critical, Fatal
Cust 3 = Clear, Indeterminate, Warning, Error, Fatal
Cust 4 = Normal, Low, Medium. High, Critical

In many of the above cases a Customer would be challenged in sending the EF severity level in a notification given with their internal mapping is either in conflict or has no context. Below is my specific mapping issue/challenge.

EF Level to Cust Level Mapping:
Critical = Fatal
Major = Critical
Minor = Major
Warning = Warning
Information = Data Issue
None = Normal

When generating Event Frames it would be useful to automatically remove the Event Frame, either when no longer active or in combination with no longer active and acknowledged, or other conditions.

An example use case would be for PI Notifications - the need to retain the Event Frames might not be there once a Notification is sent and action taken.

See https://feedback.osisoft.com/forums/555148-pi-server/suggestions/17219861-ability-to-send-a-notification-without-being-trigg

For example, I might sent a notification to remind someone to use PI Manual Logger to enter some data, but I don't need an Event Frame to exist after this is dealt with.

Other examples are that I might be using Event Frames to flag up interesting operational events on a dashboard so action can be taken, but once the event has been actioned it may no longer have any value.

In summary: auto-archive/delete/expire Event Frames based on critera such as Inactive, Acknowledged, Schedule (remove Event Frames > 1 year old), etc.

Some users asked for an enhancement of the documentation/ guide videos regarding syntax for referencing a non-primary element on a PI Point attribute from Event frame templates. The OSIsoft live guide does not provide enough information and/or examples about this and may lead to confusion.

As an example, one customer wanted to create an attribute on an Event Frame Template referencing a Pi point attribute belonging to a non-primary reference element at the same level as the primary element on the AF elements hierarchy. In order to do this, it is necessary to use the following syntax and logic:

.\Elements[.]...[@Name = <Non Primary Element>]|<Attribute>

This sets the start as the primary element, .\Elements[.], moves up one level, ..\, then down a level and chooses the non-primary reference element by using the syntax .[@Name = <Non Primary Element>]. In that element, you proceed to reference an attribute as follows: |<Attribute>

When deleting an element using PI System Explorer, there should be an option to delete all event frames that reference the element. Currently when deleting an element, the delete option "Delete this object and all references to it" does not delete the event frames that reference the element. This delete option only deletes the references that are inside the event frames.

If a deletion of an element occurs, then there could be lots of undesired event frames that have no referenced element in the database. And to find these event frames, it would be necessary to use another tool such as PI Builder to somehow filter the event frames in the AF database to the specific ones that just lost their referenced element.