In Postman, where does a collection in a shared team workspace live, and who can change it?

## The two homes a collection can have A **workspace** is space held in the vendor's account. A collection opened in a shared workspace is stored there — on their systems, reached through their application and their sign-in. The same collection can also exist as a file in your own repository, checked in beside the code it exercises. Those are two separate objects that happen to have the same content on the day somebody put them there. Nothing in either system keeps them equal afterwards, and no event in one is visible from the other. So when a team says *the collection*, it is worth asking which one they mean, because the two behave nothing alike. ## Who may change the hosted copy Access to the hosted copy is granted inside the vendor's account. That has consequences worth saying out loud: - **The editors are not your committers.** The people admitted to the workspace and the people who may merge to your default branch are two lists, maintained in two places, by possibly different people. They overlap by convention, never by construction. - **The edit is the change.** There is no staging area and no proposal. The moment somebody saves, the shared collection is different for everyone who opens it next. - **Concurrent edits are reconciled by the vendor's rules.** Whatever happens when two people touch the same request at once, it happens their way, and you learn about it by reading their application rather than by resolving a conflict. - **Leaving does not release the copy.** The document sits in an account, and an account has an owner, a subscription and an administrator, none of which is your repository. ## What your repository knows about it Nothing. That is the whole answer, and it is the part candidates skip. A hosted edit produces no commit, no author line, no diff, no reviewer and no pipeline run on your side. Therefore: - your history cannot answer *when did this change and who changed it*; - your required reviews and required checks apply to none of it; - an undo is whatever the vendor's interface offers, not a revert you perform; - if account access lapses, the copy is out of reach, whereas a checked-in file is already cloned onto every machine that ever fetched it. ## The comparison, side by side | Question | Hosted workspace copy | File in your repository | |---|---|---| | Where a change is recorded | in the vendor's account | in your repository's history | | What precedes a change | nothing; saving is the change | a commit, plus whatever review you require | | Who may change it | whoever the workspace admits | whoever may push or merge | | What a reviewer sees | the state, after the fact | the diff, before it lands | | Who meets a mistake first | the next person who opens it | the check that runs on the commit | | If account access is lost | the copy is unreachable | every clone still has it | ## Why the question comes up It separates people who have shared a collection with a team from people who have only used one alone. Alone, there is a single copy and the question never arises. On a team the collection is simultaneously a document people edit in a hurry during an incident and an input that something automated reads, and those two uses want opposite things. The hurried editor wants the change live at once; the automated consumer wants it fixed, reviewed and pinned. A hosted workspace serves the first perfectly and the second not at all. It costs nothing to add that the file-in-the-repository arrangement has the mirror-image weakness — safe and slow, and the person who wants to try one more header late at night will simply not use it. ## What to say you would do Name **one** copy authoritative and demote the other deliberately: 1. Decide which home has to be right: the one automation reads, or the one people edit by hand. 2. Say so where people will actually see it — the repository's README and the workspace's own description. 3. Make the demoted copy obviously secondary rather than merely discouraged, so nobody edits it by accident. 4. Give the demoted copy a refresh routine with a named owner, so *stale* becomes a scheduled event instead of a discovery. The failure this avoids is exactly what the interviewer is probing for: two writable homes, no shared history, and no common ancestor between them. Once both have been edited, reconciling them is a person reading two documents side by side and guessing, because the two systems never agreed on a base to compare against.