Postman is an API platform for building and using APIs. Postman simplifies each step of the API lifecycle and streamlines collaboration so you can create better APIs—faster.
[X] 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.
Is there an existing request for this feature?
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.