Variable Scope Precedence

If I understand correctly, if you reference a variable in a request URL / body then the precedence for resolving that variable based on the name should be:

1st: Runtime/local variable
2nd: Collection variable
3rd: Environment variable

I’m seeing environment take precedence over collection when both are defined. I just wanted to check if this was a bug before I file on GitHub. I have created a test collection/env file for this but I am not sure how to attach it.

I poked around and found this: https://learning.getpostman.com/docs/postman/environments_and_globals/variables/

According to this, env is a more ‘specific’ scope than collection.

I’d like to challenge that, considering many requests in many collections can use the same environment variables, but many requests in many collections cannot use the same collection variables.

Hey @morleym_cubic,

What command are you using to call the Collection Variable in this case?

@dannydainton I have shared a test collection for this purpose here (instructions are in the collection description for creating the environment and adding the environment variable)

https://www.getpostman.com/collections/25608afef3e1d2cd1fcc

To directly answer your question: I’m not using any command to call the variable. I am referencing it in a request body/url (body, in this case, using {{variableName}})

1 Like

Again, I understand now that this is expected behavior according to https://learning.getpostman.com/docs/postman/environments_and_globals/variables/

But hopefully this use case (especially with the recent change to enable write access to collection variables from scripts) highlights my argument for collection variables being a more specific scope than environment variables (and thus, being used when there are variables of the same name for both scopes)

@dannydainton I’d like to revisit this topic because I’ve been seeing my teammates run into this collision problem frequently. For context, they’re working to replace local variable usage with collection variable usage (since this allows for ‘clicking through’ a collection one request at a time, something impossible with local variables). This is for collections where we’re:

  • Generating a unique value at runtime. e.g. creating a value for email address for an account creation request, and then referencing it in the tests of later requests in that collection
  • Storing something from one request’s response and then using it in a later request in that collection. e.g. storing an auth token value from an authenticate response to reference in the headers for an account details request afterwards

Our only solution currently for env/collection collisions is “just don’t have any collisions” (for example, if someone needs an environment-specific valid password to use while testing an account creation endpoint, then the env value should be called valid_password and not password). We will make do with that.

Still, I’d like to make the case that when resolving a variable reference in a request url/body with {{variableName}} the order of precedence should go:

1st: local, which can be used across an execution (as specific as a single request)
2nd: collection, which can be used across a collection
3rd: environment, which can be used across collections
4th: global, which can be used across collections and across environments

Not sure where ‘data’ falls in this list (I suppose after local and before collection), but isn’t super relevant to our team right now. The main disagreement I have with the current behavior is that environment variables, which can be used in a wider scope (across collections), are being considered more specific than collection variables (which can only be used within a collection). Conceptually, I find that incorrect.

I understand this would be an impactful change if anyone’s relying on env > collection in their teams today, so it’s not a light decision to make. But, given the recent addition of pm.collectionVariables.set() (and thank you so much for doing so!), this feels like the next step towards minimizing scope pollution.