Collection Variables: Scoped Defaults
Collection variables live inside a specific collection's settings and act as default values available to every request in that collection, regardless of which environment is active — useful for things like a fixed API version path that never changes across dev, staging, or prod. Because they travel with the collection file itself, they're shared automatically with anyone you share or export the collection to.
Cricket analogy: A collection variable is like a franchise's fixed home-ground pitch report baked into their season planner — it doesn't change whether they're playing a day game or a day-night fixture, and it travels with the franchise's playbook wherever it goes.
Global Variables: Workspace-Wide Values
Global variables are visible to every collection and every request in a workspace, making them the broadest scope in Postman — handy for a personal debugging flag or a value you genuinely need everywhere, but risky as a default because they silently apply to collections you didn't intend, including ones built by teammates.
Cricket analogy: A global variable is like a single umpire's personal notebook rule that quietly applies to every match he officiates that season, even fixtures where the two boards never agreed to it — convenient for him, but confusing if teams weren't expecting it.
// Setting a collection variable (available to every request in this collection)
pm.collectionVariables.set("apiVersion", "v2");
// Setting a global variable (available in every collection in the workspace)
pm.globals.set("debugMode", "true");
// Reading them back inside a request URL
// GET {{base_url}}/{{apiVersion}}/usersGlobal variables are shared across every collection in a workspace, so a script that calls pm.globals.set() during one team's testing can silently affect an unrelated collection someone else is running in the same workspace — this kind of test pollution is hard to trace back to its source.
Choosing Between Environment, Collection, and Global Scope
The practical rule is to scope as narrowly as possible: use environment variables for anything that changes between dev/staging/prod (URLs, tokens), collection variables for constants specific to one API surface (a fixed sub-path, a shared test resource ID), and reserve globals for the rare value that must be visible across otherwise-unrelated collections in the same workspace.
Cricket analogy: Choosing the right scope is like a coach deciding which instructions go on the team sheet, per-match, like today's batting order, which go in the season playbook, per-campaign, like the fielding philosophy, and which are simply league rules everyone follows regardless of team.
Because global scope is checked last in Postman's resolution order, a forgotten global variable from months ago can silently supply a fallback value for a request that looks correctly configured otherwise — periodically audit and prune unused globals.
- Collection variables are defaults scoped to one collection and travel with it when shared or exported.
- Global variables are visible across every collection in a workspace — the broadest and riskiest scope.
- Scope narrowly: environment for things that change per stage, collection for constants specific to one API, global only when truly needed everywhere.
- pm.collectionVariables.set() writes to collection scope; pm.globals.set() writes to global scope.
- Global scope is checked last in resolution order, making stale globals easy to overlook.
- Overusing globals causes hidden coupling and test pollution across unrelated collections.
- Collection variables are ideal for values like a fixed API version path that never changes across environments.
Practice what you learned
1. What is the main characteristic of a collection variable?
2. What makes global variables risky as a default choice?
3. Which function sets a variable scoped to the current collection from a script?
4. In Postman's resolution order, when is global scope checked?
5. When is it appropriate to use a global variable instead of a collection variable?
Was this page helpful?
You May Also Like
Environments and Variables
Understand how Postman Environments let you swap base URLs, tokens, and config values between dev, staging, and production without editing every request.
Collections Basics
Learn how Postman Collections group related API requests into a single organized, shareable, and runnable unit.
Organizing Requests with Folders
Learn how to use folders inside a Postman Collection to group related requests, apply shared settings, and control execution order at scale.