Hello,
Following our evaluation of the Version Management feature (Environment Configurations) after its General Availability announcement, we would like to share some product feedback based on our sandbox testing. We hope these observations are useful as you continue to develop and refine the feature.
1. Snapshot language limitation & Production to Production environments restore restriction
We encountered two notable limitations around Snapshots:
Language dependency - The language of a Snapshot is tied to the account language at the time it is taken. When attempting to deploy from a Snapshot created in one language (for example Portuguese) to an environment set to a different language (to English), the deployment fails. There is no warning or indication of this at the point of taking the Snapshot or initiating the deployment, which makes troubleshooting unnecessarily difficult. We would suggest either making Snapshots language-agnostic, or surfacing a clear warning when a language mismatch is detected before deployment begins.
Production to Production restore restriction - For plans below Enterprise (which do not include a Sandbox), the ability to restore a Snapshot back to Production is directly tied to the existence of a Sandbox environment. This feels like a significant limitation, as it restricts access to a core recovery capability based on plan tier. We would welcome a review of this dependency, or at minimum clearer documentation around it.
2. Lack of detailed error information when deployments fail
When a deployment test fails, the feature currently notifies the user that the test was unsuccessful but does not provide specific details on why individual items failed. Similarly, Partially Deployed statuses indicate what was not pushed, but not the reason behind it.
For a feature that manages configuration changes across environments, actionable error information is essential. Without it, admins are left guessing, which increases the risk of repeated failures or incorrect workarounds. We would strongly encourage more granular and descriptive error outputs - ideally identifying the specific configuration item, the reason for failure, and a suggested resolution where possible.
3. No indication of who triggered a deployment
Currently, there is no visible record within the Version Management feature of which admin initiated a specific deployment. While the Audit Log may capture some changes, this is not surfaced directly within the Deployments view itself.
For accountability and governance purposes - particularly in environments with multiple admins - knowing who triggered a deployment is important. We would suggest adding an "Initiated by" field to each Deployment record, visible directly within the Version Management interface.
We believe Version Management has strong potential and are encouraged by the direction of this feature.
We hope this feedback helps prioritize improvements that would make it more robust and trustworthy for production usage.