The current method for adding columns and changing their Data Content type (value, average, min, max, etc) is clunky and time consuming.  You can only change (or add) one column at a time, and you have to wait for the data view to refresh after each change.

Ideally, I would like to have the ability to switch from the default UI (Column headers with real data) to a configuration UI that has a more tabular configuraiton layout or a layout similar to AF. 

I want to be able to select multiple data items and change them all to be "Average" instead of "Value".  I want to be able to rename one column and then quickly move on and rename another without having to wait for any sort of delay or processing.  Ideally, I'd like to be able to export the configuration to JSON or csv, edit it, and then import it as well.

This would greatly speed up the views that I publish that require average values for all of the tag data

Add product specific Perfmon counters for Pi4BA, including specific counters for the Integrator Service, the Data Sync, and Worker processes, beyond the standard windows process data - Such as # active sessions, # views, # of AF syncs, number of views processed per worker, view status.

There was a previous feedback request that was marked as completed, as now some of this info is currently stored in the statistics table, but there is a separate table by view GUID, and a row of data stored per run per view - and the "stats" column seems to be encoded, making programatic reads, and parsing of the statistics more difficult.

Exposing this data to Perfmon counters would better allow PI notifications and other generic windows tools to leverage this status/health info. As well allow the PI Perfmon interface to store this data in PI, allowing trending, etc.

Bottom line, link most PI products, Pi4BA should expose Perfmon counters as to improve visibility around it's health and current status

When a PI View is deleted from the Integrator User Interface, the Publication Metadata and target data tables are both deleted for that view. For a view with a non-PI View target such as a SQL target, however, only the Publication Metadata table is deleted. The Integrator will no longer consider that view name to be reserved after deleting the view, but using that name again for a new view with the same target requires us to manually delete the target table if there is a change to the shape or we do not want to append to the existing data table. It would be great to have an option to decide whether to delete the target data table as well when a view is deleted.

I would like the option to remove or disable the "PI View" target on the Data Warehouse, Azure, and SAP Hana editions. 

In these editions, the PIIntegratorDB is expected to remain small because the data is published out to a separate database.  The problem, however, is that users may accidentally publish very large views to the "PI View" target instead of, for example, Azure Data Lake.  This can fill up drive space on the SQL server and prevent the Integrator (or other services that rely on that SQL server) from running.

For these editions, most users will not be publishing to PI Views, so we should have the option to remove that target.

The Integrator for BA appears to be a great fit for exporting event-based data such as Batch Interface Messages to external systems. Interpolation doesn’t apply in these cases so we can use a tag as the ‘Key’ in value mode selection.
However, there are cases where a tag can have multiple entries at a given timestamp (e.g. EMDVB Recipe Parameter Downloads) and the current behavior is to only include the first value in the output view. This approach results in missing data and makes the integrator unusable in these cases.
Ideally the view would return all records (as per PI OLEDB) or provide a selection to allow the user decide how it should behave