When a tag on the publisher side is renamed, the tagname on the subscriber side does not get changed to the new name.
As a subscriber, I would like to have an option when setting up the subscription, to flag the subscription so that if a tag within it is renamed, I can select the flag and the tag names on the subscriber would also be changed ( AF, SMT etc).

As a Publisher, I would like a feature that allows me to republish my AF Hierarchy SO THAT I can quickly address any discrepancies between my system and a Subscribers.

It would be useful for the PI Cloud Connect (PICC) portal to include logs related to user activity on the portal such as subscriptions, users, or publications added or removed. The current logs are local and service specific. An enhancement of PICC logging on the portal would be very helpful.

Currently, the customers are expected to monitor the PI Square post here for see updates about a release : https://pisquare.osisoft.com/community/all-things-pi/pi-cloud-connect/release-notes.

The problem with this is that:
1) Not all customers are aware of this expectation
2) Customer will have to login to see the releases which is not very user friendly

It might be better to send the information via email.

I would like to see increased level of logging to identify potential issues with the operation of PICC especially since the alarms page is deprecated.

As a customer I want to be notified when there are issues with PICC instead of having to actively query the health of PICC, so that I can be aware of issues immediately.

As a customer I want an easy way to validate that all the data from publisher side went to the subscriber side, so I know if there are any issues.

This will make the website faster and more secure.

HTTP/2 will make the website load faster. OSIsoft's other websites use it.

HTTP/2 check:
https://http2.pro/check?url=https%3A//www.picloudservices.com/

As a PI Cloud Connect Subscriber, I would like annotations from the Publisher to be replicated so that I can have all of the information associated to the PI Tags

Prior to be able to adopt PI Cloud Connect, many of our customer cybersecurity teams request OSIsoft to provide SSAE SOC2 cybersecurity audit reports. Currently OSIsoft does cybersecurity audits, but these are not specifically SOC2 audits. This is a request to provide these audits that better fit into the industry trend seen at our customer base.

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.

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

To help 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 lower.

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.

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?

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.

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.