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:

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.

1 Like

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)

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}})


Again, I understand now that this is expected behavior according to

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)

1 Like

@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.

1 Like

Hi there
I to think it not very usefull, that environment variables take precedens over collection variables. As @morleym_cubic expresses, collection is a narrower scope than environment. By the current behavior, it is not possible to override an evironment variable with a collection variable. So we can not have different collections that uses local values to replace default values in the environment.

1 Like

According to Postman docs: , collections are a narrower scope than environments and a collection variable should take precedence over an enviroment variable. The principle is mentioned in the docs for global and local:

If a variable with the same name is declared in two different scopes, the value stored in the variable with narrowest scope will be used—for example if there is a global and a local variable both named username , the local value will be used when the request runs.

So it seems clearly to be a bug that environment variables override collection variables.

Hi there, the part of the docs you’ve linked to indicates environment variables are closer scope than collection and therefore should override collection values - is there somewhere in the docs you’ve seen the info imply that collections are narrower scope? Just in case we need to update the docs…

Oh, you are right. Sorry, I was wrong about the docs - thanks for pointing that out.

But like @morleym_cubic, I really think collection variables naturally fits as a more specific scope than environment variables. As @morleym_cubic puts it:

…many requests in many collections can use the same environment variables, but many requests in many collections cannot use the same collection variables

In my opinion, that observation alone sets the hierachy.

1 Like

I just realized, that global scope is local to workspace, which makes it what I wanted environment scope to be.

So, @morleym_cubic, I’m not shure if there would still be a reason to promote environment scope?

Hi guys! I have the same issue. I see many suggestions and explanations here, but who tries them all? Have you found the most appropriate solution? In my case, nothing helps actually, and it is very disappointing for me. It can also mean that I am doing something wrong. I am from Spain, if it matters. Waiting for your opinions.

hi Sue, I believe these 2 articles present diverging statements regarding precedence:

Hi @ObjectIsAdvantag! Thanks for reporting this, we are actually in the process of migrating our support FAQs into the learning center so I’ll make sure this gets addressed in the process! :raised_hands:

Hi Sue,

This article also has the incorrect scope description:


Hi @ecv_zen, can you be more specific about what you’re finding incorrect in that page?