Your team reviews Postman collection changes inside the vendor's workspace rather than in pull requests — what does that cost?

## What actually moves when review moves Reviewing collection changes inside a vendor-held workspace is not the same activity done elsewhere; it is a different activity with the same name. In your repository, a change is a **proposal**: it exists, visibly, before it takes effect, and something has to accept it. In a hosted workspace, acceptance and effect are the same instant, and the record of both is kept by the vendor. Everything below follows from that one difference. ## The four losses - **History.** Your repository holds no commit, no author, no diff and no message for the change. The question *what changed, when, and why* has an answer only inside their application, in whatever form and for however long they choose to keep it. An auditor asking your repository gets silence, and silence reads as *it never happened*. - **Gates.** Required reviews and required checks act on things proposed to your repository. A workspace change is proposed to the workspace. There is nothing for your gate to refuse, which means the gate is not lenient here — it is absent. - **Notification.** A failing build tells somebody, by name, promptly, with a link. An accepted workspace change tells nobody. The failure surfaces when a person opens the collection, runs a request and finds it broken, which may be a day later and is likely to be during something else that matters. - **Recovery.** Undo is whatever the vendor's interface offers. It is not a revert you can perform, script, or apply from a machine that still has a clone. ## Where a change is reviewed, side by side | | Reviewed in your repository | Reviewed in the workspace | |---|---|---| | Exists before it takes effect | yes, as a proposal | no; acceptance is the change | | Who may accept it | your repository's reviewers | the workspace's own access list | | What is recorded, and where | your history | the vendor's record, in their application | | What can refuse it | your required checks | nothing on your side | | Who is told when it is wrong | the pipeline, immediately | the next person who opens it | | How it is undone | a revert you perform | whatever their interface offers | ## The failure this produces in practice The damaging case is not a bad change; it is a **divided subject**. The team also keeps the collection as a file in the repository, because something automated reads it. Somebody fixes a request in the workspace, because that is where the application is open and the incident is now. The fix is accepted, everyone sees it, everyone believes the problem is closed. The repository copy is unchanged, so the automated consumer keeps running the old definition, and the next person to compare the two finds two documents that have both moved with no common ancestor to compare against. Nobody was negligent. The arrangement guaranteed it. ## When reviewing there is nevertheless right It is right when the workspace genuinely owns the document and nothing automated reads it: 1. The people who must change it — support engineers, analysts, a partner team — have no repository access and should not be given some, purely to edit a request. 2. The collection is an exploration surface: it describes what somebody tried, not what the system is contractually expected to do. 3. Speed during an incident is worth more than the record, and the team has decided that consciously rather than by drifting into it. In that case, the vendor's review is doing real work and demanding a pull request would only push people back to editing without any review at all. ## The arrangement to propose - **Split the subject, not the process.** Decide which changes may originate in the workspace at all. Exploratory edits, yes. Anything an automated consumer depends on, no. - **Make the authoritative copy obvious in both places** — in the repository's README and in the workspace's own description — so nobody has to guess which document they are looking at. - **Give the non-authoritative copy an owner and a refresh routine**, so *stale* is a scheduled event rather than a discovery during an incident. - **Assume no notification exists.** If something matters enough to be told about promptly, it is read from the repository copy by something that can fail loudly, not from the workspace. - **Write down what happens if the account is unreachable.** Access to the review record, the history and the document itself all depend on an account your organisation may not administer. The answer an interviewer is listening for is not *pull requests are better*. It is that the two arrangements have different subjects: one optimises for a record and a gate, the other for immediacy and reach, and picking one per kind of change is a decision to make on purpose.