Variable Scope Precedence

šŸ™‹ Help
1

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.

2

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.

3

Hey @morleym_cubic,

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

4

@danny-dainton 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
5

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)

1 Like
6

@danny-dainton 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
7

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.

2 Likes
8

According to Postman docs: https://learning.postman.com/docs/postman/variables-and-environments/variables/#variable-scopes , 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.

9

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ā€¦

10

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
11

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?

12

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, https://worldcams.tv/spain/lanzarote/airport if it matters. Waiting for your opinions.

13

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

14

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:

15

Hi Sue,

This article also has the incorrect scope description:

Thanks.

16

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

17

Hi,
The correct order of variable access in Postman, from highest to lowest priority, is as follows:

  1. Runtime/Local Variable: Runtime or local variables have the highest priority and are accessible only within the specific request or script where they are defined. They override variables of the same name in any other scope.
  2. Environment Variable: If a variable with the same name is not found as a runtime/local variable, Postman will look for an environment variable. Environment variables are specific to an environment and are accessible to all requests within that environment. They override variables of the same name at the collection and global scope.
  3. Collection Variable: If a variable is not found as a runtime/local or environment variable, Postman will check if it exists as a collection variable. Collection variables are defined at the collection level and are accessible to all requests within that collection. They override variables of the same name at the global scope.
  4. Global Variable: If a variable is not found as a runtime/local, environment, or collection variable, Postman will look for it as a global variable. Global variables have the lowest priority and are accessible across all collections and environments in Postman. They serve as default values and are overridden by variables of the same name in any other scope.

Therefore, if the same variable name exists in all four scopes, the order of access will be:

  1. Runtime/Local Variable (highest priority)
  2. Environment Variable
  3. Collection Variable
  4. Global Variable (lowest priority)
18

Actually, I do agree that Environment variables take precedence over Collection. We set the default (and published as public) variables in Collection. But for our testing and staging servers etc, we can override these by creating Environment variables, which are all non-public.
I think the problem is more about how the software/UI is designed. It gives a sense that Environments are the top level, because they are right there in the main navigation.