We are currently working with eight environments in Postman and would like to share a few observations regarding environment variable handling. It is possible that we are missing something, so we would appreciate clarification from the community or the Postman team.
Adding new variables
We noticed that new variables can only be added at the end of the variable list. With more than 50 variables, this requires a lot of scrolling. Additionally, when a filter is active, we could not find a way to add a new variable. We may be overlooking an existing option, but an explicit “Add variable” button that works regardless of filtering would be very helpful.
Shared value vs. environment-specific value
The handling of shared values is not fully clear to us. When no environment-specific value is set, the shared value does not seem to be used automatically. We may be misunderstanding the intended behavior, but this raises the question of what role the shared value is meant to play. Treating it as a default fallback would feel more intuitive and could help reduce duplication.
Any clarification or best practices around these points would be greatly appreciated.
It makes sense to have a more accessible “Add variable” option that isn’t restricted to the bottom of the list or dependent on filters. This usability enhancement will be added soon.
Regarding shared values - they’re meant for collaboration, allowing values to be shared and synced across a workspace for your teammates. These synced values will be used for your cloud operations such as monitors and scheduled runs.
For request execution, we intentionally rely only on explicitly set local values, so it’s always clear which values are being used at runtime. This avoids implicit behaviour and ensures predictable, safe execution. More information regarding variables can be found on our docs.
You can always reset your shared value to your local value to then use it in your requests.
Thanks @apoorvgupta03 for the quick response and the clarification. Much appreciated.
I’m also glad to hear that an improved “Add variable” option is coming — that will definitely help when working with larger environments.
Regarding the shared vs. local value behavior, I’d like to add one remark:
With environments that contain 50+ variables, a full “Reset all” is of limited practical use. In real-world scenarios, it’s quite common to intentionally override only a few variables locally while keeping the rest aligned with the shared values — and to keep those local deviations over time.
Additionally, from a collaboration perspective, requiring an extra step (resetting shared values to local ones) before requests can run feels somewhat counter-intuitive. Especially for new team members, it’s not always obvious why requests don’t work even though shared values are present.
I understand the motivation for avoiding implicit behavior, but a clearer or more ergonomic way to leverage shared values — without forcing a global reset — would significantly improve usability in collaborative setups.
Thanks again for the insights and for considering these points.
Thanks @sladjo for sharing more details about your workflow.
Since request execution relies on your local values, on hovering over the variables used in the request, you can see the value that will be used at the time of request sending.
If you have a shared value for that variable which is different from the local value, you’ll also see an option to reset the shared value to your local value at the time you want to send the request.
This keeps execution predictable while still allowing shared values to stay in sync with collaborators when you explicitly choose to update them.
@apoorvgupta03 Thanks for the explanation and for taking the time to clarify the rationale behind this behavior.
If this is the only supported way environment values can work, I understand that it’s ultimately a trade-off — optimizing for explicitness and predictability will inevitably leave some workflows less well served. If the behavior were closer to what I personally prefer, there would likely be other users who would be unhappy instead.
What I still find problematic, though, is the onboarding experience. When a new teammate joins, I have to explicitly tell them: “Before anything works, you need to go through all environments and reset the values, otherwise none of the requests will run.”
That means Postman does not work out of the box for new users, and additional, non-obvious setup steps are required before they can be productive.
From a collaboration and usability perspective, this remains a friction point, even if the underlying design decision is understandable.