Be able to backfill data for a significant amount of time if there is a undetected or temporary uncorrectable network failure.

Allow history recovery for PI Cloud Connect to be longer than the current max of 30 days

I am a subscriber who receives data from multiple organizations in different (>15) subscriptions. Due to needing the data to be located in different Data Archives as each is for a different business area, one instance of PI Cloud Connect should be able to write to multiple Data Archives, instead of just to the default data server on its node.

As an administrator, if I were to move my PI Cloud Connect nodes to new machines, I would like the ability to clean up my tenant portal by removing old system names that are still present.

I cannot use my Office365 account to activate my PI Cloud Connect account, because it is a compliance issue in my company to use any other account but the Office365 account to activate this.

As a regulated customer, I need OSIsoft to give me advanced warning on changes to the service offering of up to 4 weeks SO THAT we can get our change controls pre-approved and ready before OSIsoft pushes their changes. OSIsoft needs to communicate what the hotfix is, what are the updates, what modules are affected.

PI Cloud Connect seems to use the insert write mode for all PI tags. When replace write mode is desired (for example, for laboratory data), this is possible on the publishing archive but not through PI Cloud Connect. This results in multiple values being written to a PI Point at the same timestamp. The ability to switch to the replace write mode for individual tags in PI Cloud Connect would improve the service.

When setting up PI Cloud Connect subscriptions it would be nice to specify the PI Data Archive tags get created on along with the AF Server and Database to create elements. In our case, we have multiple AF Servers that are linked to different PI Data Archives. Additionally, I don't really like that the default PI Data Archive gets used. What if a user were to accidentally change that?

As a regulated customer, I need the ability to test SaaS service updates on a test system before they are rolled into production SO THAT we can have confidence that the changes won't adversely impact our system and we can maintain validation compliance.

As a administrator, I would like PI tag data type changes (ex: string to Float64) to not cause data to stop streaming/updating for the tag SO THAT I don’t have to manage this situation manually every time it happens.

As a subscriber to data, I would like to control updates & deletes to data changes SO THAT the original raw data sent to us from the publisher can remain even if it was deleted on the publisher side

PI Cloud Connect currently scores an A from Security Headers. However, this can be improved to an A+ by addressing the issues in the link below.
https://securityheaders.com/?q=www.picloudservices.com&followRedirects=on

As a PI Cloud Connect user, I would like to screen receiving Vendors via their account, but by also by limiting connections to a specific IP or IP range for connections.

Allow administrators the ability to configure the PI Cloud Connect agent on-prem to configure a group managed service account (gMSA) for the Windows Service account.

Use of a gMSA reduces IT burden since the rotation of credentials with strong credentials is handled automatically. Furthermore, gMSAs generally improve security as they are hardened by default.

As a PI Cloud Connect subscriber, I would like for PI tags that have been edited or deleted on the publisher end to be marked (renamed or otherwise) on my PI Server, so that I can tell when tags are no longer needed. This way, I can also determine if a tag is not updating because it has been edited/deleted, OR if the tag isn't updating because of a different issue.

PI Connect should auto-resolve the proxy settings, but then allow the administrator to either set them manually or update them.

To ensure that no insecure HTTP requests are attempted against picloudservices.com, please consider submitting it for HSTS preloading.
https://hstspreload.org/?domain=picloudservices.com

Before that can happen, some redirects must be set up. http://picloudservices.com should redirect to https://picloudservices.com, and https://picloudservices.com should redirect to https://www.picloudservices.com.

Since picloudservices.com is used for a much narrower purpose than osisoft.com, the barrier to submission for HSTS preloading should be much less.

Problems as:
- PI Cloud Connect node cannot connect to PI Data Archive,
- Account/Password has been expired (service not running properly),
- Publications not sending data,
and so on. Would be reported to administrators automaticky.