1. AF Transformer should be able to sync changes made in the source AF Database: if an element is added, deleted or edited.  For the deletions there should be a way to select the behavior: delete an object from the target database, place it under a different hierarchy, rename or do nothing. 


2. It would be also helpful to have an additional AF property in AF - deletion flag. A power user will be reviewing a list of elements flagged for deletion and will be making a decision - delete, rename, move or do nothing (similar to functionality in the connectors admin page).


3. Changes (especially deletions and edits) should be logged with different level of details based on the debug level specified.

It can be difficult to locate an analysis group in the current (2.9.5) UI for the Analysis Statistics in a large system. Currently the groups are organized in decreasing order of lag which is great to troubleshoot latency issues. However, if one wants to keep an eye on the performance of a particular group, they must scroll through the list to find the group which can be painful in a large system. This comes up frequently when trying to see if a group is has some skip counts.

One way of improving the UI could be to include the type of analysis along with the group name (Expression, Rollup or Event Frame).

Right now BadVal can only check one variable or Expression.  So if I am evaluating an expression with say 10 inputs, and I want the expression to output NoOutput() if any one of the 10 inputs are BadVal, then I have 2 options right now. 

1) copy the whole expression into the BadVal funtion and do "if badval(expression) then NoOutput() Else expression".

2) Do "if (BadVal(input1) or BadVal(input2) or ...) then NoOutput() else expression".

Ideally you would have a IFERROR function like in Excel.  So you would just type "IFERROR(expression,NoOutput())

Alternatively you could have BadVal allow multuple inputes.  So "If BadVal(input1,input2,input2,...) then NoOutput() else expression"

I'm sure one of these options is more resource efficient then the currently available options.

When the PI Analysis service determines an Analysis should be Suspended, it should also set any output Attributes to be Excluded. As the Analysis is Suspended, it will not output any results and if it has always been Suspended, the output Tags will never get created. Excluding the output Attributes will keep the Element looking clean and also allow dependent Analyses to go into a Suspended state instead of throwing an error when they can't find the Tags. Similarly it will prevent other applications (OSIsoft and third parties) from querying the Attributes and also throwing errors, causing performance issues.

Automatically suspended Analyses when the inputs are excluded was an extremely useful feature and has made supporting and maintaining an AF database easier. Automatically excluding the output attributes is a natural progression of this feature and will make AF database even more easier to maintain.

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

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.