Granular level permission for Postman Environments

[sanmania]

Is there an existing request for this feature?

• I have searched the existing issues for this feature request and I know that duplicates will be closed

Is your feature request related to a problem?

Users have occasionally deleted environments, which often contain sensitive information and are time-consuming to set up due to the multiple environments required per workspace. Currently, Postman does not back up environments, meaning they cannot be restored once deleted. The only recovery option is to manually re-create them. When environments are lost, it can also halt work, causing delays until they are restored.
A workaround is to have designated individuals back up these environments, create a separate workspace (Postman recommended approach) or implement an automated job that stores snapshots within our systems. However, these approaches are cumbersome and prone to issues such as expiring SCIM keys, employee turnover, role changes, additional workspace management, and accidental deletions.

Describe the solution you'd like

We propose implementing more explicit permissions for managing environments by setting default access to read-only, except for workspace owners/admins. Teams would need to submit a ticket to the designated Admin team for any environment modifications. In cases where no Admin is assigned (noting that PayPal currently has 2,600 workspaces with universal Admin access of which many do not have a individual admin, which presents its own challenges), users requesting edit permissions for environments would need to initiate a ticket. This approach would centralize environment management, establishing a controlled system to safeguard sensitive information and ensure secure, effective handling.

Describe alternatives you've considered

We have reviewed various workaround solutions. In the absence of the desired solution, we may ask teams to create a separate workspace to control permissions more effectively. However, this approach may introduce confusion and additional management overhead, as it increases the risk of other artifacts, such as tests, mocks, and collections, being created in these environment workspaces.

Additional context

An incident occurred when a user accidentally deleted multiple environments in a team workspace, mistaking it for a private workspace. This deletion blocked the team's work, led to an internal escalation, and highlighted the need for more granular controls specifically for environments, which are widely used and shared. Although some environments were eventually recovered, the process was time-consuming.
The incident underscored a general consensus that, while collections need to remain editable by contributors, environments are typically more static, stable, and referenced across all collections. The lack of dedicated controls for environments feels counterintuitive and introduces the risk of significant disruptions.