Why does a value held in Postman's pm.globals not reach a teammate who imports your collection?
answer
- Ask what the file actually contains
- One store has no field anywhere
- Nothing to write out, nothing to read back
- No collection schema declares it
basics
~10 sNo collection schema describes a globals store at all. It is held outside the collection document, so an export carries the file's own variable array and nothing whatsoever from pm.globals.
solid answer
~40 s`pm.globals` is a sandbox handle onto a store the **collection format describes nowhere**. There is no globals field in a collection document, so there is nothing for an export to write out and nothing for an import to restore. What you hand a teammate is the file, and the file carries `info`, `item` and the collection's own `variable` array — the globals store is not in it. That makes a global effectively per-installation state: real while your session runs, invisible to anyone you send the collection to, and absent on any machine that has only the file. Anything a teammate must have in order to run the collection therefore belongs somewhere that is itself an artefact, starting with the collection document's own `variable` array.
code
javascript · 2 linesconst fromFile = pm.collectionVariables.get('baseUrl');
const fromMachine = pm.globals.get('baseUrl');go deeper
Be ready to state the outcome plainly: a value kept in pm.globals stays on your installation, so a teammate who imports the collection file does not get it.
Explain the mechanism, not just the symptom. No collection schema declares a globals store, so there is no field to write on export and none to read on import.
Diagnose it in the wild. When a collection is green for you and red for everyone else on first run, look for values that were only ever seeded into the globals store.
Set the rule that prevents it: a collection is only shippable when the document itself declares everything a fresh machine needs to run it, and reviews enforce that.
## The asymmetry in one line A Postman collection is a JSON document, and the **collection format** — the schema for what such a document may contain — declares an array named `variable` on it. That array is a field of the file. The store reached from a script as **`pm.globals`** has no counterpart anywhere in that schema: **no collection schema declares a globals store at all**. One of the two stores is written into the artefact you share; the other belongs to no file. Everything the question asks about falls out of that asymmetry. ## What 'described by no schema' actually means A schema is the contract for what a document may contain. If the contract names no place for a thing, the document has nowhere to put it: - there is no globals key to write when the collection is serialised, so an export cannot include it; - there is no globals key to read when the collection is parsed, so an import cannot restore it; - and a tool reading the file cannot infer it, because nothing in the file hints that it existed. This is not a rule the product chose to apply to your data. It is a **shape the format does not have**. `pm.globals` still works while your run is in progress — the sandbox gives you a real handle onto a real store — but that store is supplied from outside the document and stays outside it. ## The two stores side by side | | The collection's own `variable` array | The store behind `pm.globals` | |---|---|---| | Declared by the collection format | Yes | No | | Written into the collection document | Yes | No | | Comes with an export, an import, a commit | Yes | No | | Reached from a script as | `pm.collectionVariables` | `pm.globals` | | Effective lifetime for other people | As long as they hold the file | Only on the installation that has it | ## The consequences an interviewer wants you to name The mechanism is small; the symptoms it produces are the interesting part: 1. **Works on my machine.** Your run resolved a value from a store nobody else has, so your green result proves nothing about anybody else's. 2. **First run after import fails.** The teammate's collection is complete and correct as a document, yet a value it needs was never in the document. 3. **A headless run has nothing.** A run driven from files starts from the files it was handed, and the collection carries none of your globals. Which switches feed such a run additional files is the runner's own subject. 4. **Nothing to review.** A global you changed produces no diff anywhere, so no reviewer ever saw it and no history records it. 5. **Nothing to reproduce.** A fresh checkout on a fresh machine cannot recreate a value that was never serialised. ## Making the collection runnable for somebody else The fix is to move the value into something that is itself an artefact: - put what everyone needs identically into the collection document's own `variable` array, since that array ships inside the file you are already handing over; - put what differs per person or per deployment into a file they are also given rather than into a store only your installation has; - treat `pm.globals` as scratch space for the session you are in, never as the place a shared collection expects to find something. A useful habit when a collection is about to leave your machine: read it as though you were the recipient, with only that file in hand. Any name the requests depend on that the document does not declare is a value you are quietly supplying yourself. ## Where the boundary is This question is about **where each store lives**, and stops there: - which store answers when the same name sits in several of them is resolution mechanics, a separate subject; - the structure of a per-deployment file of values belongs to the environment store's own topic; - keeping a credential out of a shared document has its own mechanism, and its own question; - and moving a value from one request to the next during a run is a flow question, not a storage one. The answer here is one sentence with one reason behind it: a global does not travel with a shared collection because no collection schema has a place for it, so the file you share was never carrying it.
- Then where should a value a teammate needs in order to run the collection live?In the collection document's own `variable` array, because that array is a field of the file you are already handing over, so it arrives on import without any extra step. If the value legitimately differs per person or per deployment, it belongs in a file they are also given rather than in a store that exists only on your installation.
- Does a run started on a build machine begin with your globals?No. Such a run sees the files it is handed, and the collection document has no globals in it, so a value that only ever existed in `pm.globals` is simply absent. Which command-line switches feed a headless run extra files is the runner's own subject, not something the collection format decides.
Sharing the collection is like posting a filled-in form: everything written on the sheet arrives with it, and everything you only ever kept on the notepad beside the sheet does not.
saying these in an interview costs you the question
- Claims globals are stored in the collection's info block
- Says exporting a collection includes the global store
- Assumes globals are shared with the team automatically
- Treats pm.globals as a synonym for pm.collectionVariables
- Thinks the format has a globals field that export skips