In a large shared Postman collection, how does protocolProfileBehavior inheritance differ from auth and event inheritance?

## Three surfaces, three answers A Postman collection is a tree, and several different things declared on that tree are inherited by the entries below. Candidates get into trouble by learning one inheritance rule and assuming it generalises. It does not: **there are three surfaces and three unrelated rules**. 1. **Declared credentials** resolve to **one**. The nearest applicable declaration governs the send; the others do not contribute. 2. **Inherited scripts** **stack**. Ancestors' listeners and the entry's own all run; none of them wins over another. 3. **`protocolProfileBehavior`** **merges per member**. Every ancestor's block contributes, and for each individual member the nearest declaration wins. The first two have their own topics and their own mechanics; the point here is the contrast that makes the third one distinctive. ## The contrast in one table | Surface | What inheritance produces | What a nearer declaration does | |---|---|---| | Declared credentials | exactly one declaration in force | replaces the ancestor's outright | | Inherited scripts | all of them, run in sequence | adds to what already runs | | `protocolProfileBehavior` | one merged object of members | overrides only the members it names | ## Why the behaviour block is the odd one The merge is what makes it different from both neighbours: - Unlike credentials, **more than one level contributes to the result at the same time**. A root can supply `strictSSL` while a request supplies `followRedirects`, and both are in force for that send. - Unlike scripts, **the levels do not accumulate work**. Each member ends as a single value, not a list of values applied in turn. - A request-level block is therefore a **narrow override**, not a replacement. Declaring one member changes that member and nothing else. - After the merge, the runtime resolves the result through `resolveWithProtocolProfileBehavior()` against `defaultOpts`, so a member nobody declared still has a value at send time. Neither of the other two surfaces has an equivalent silent fallback with the same shape. Mechanically, the SDK's `Item#getProtocolProfileBehaviorResolved` walks the item's ancestors with `forEachParent({withRoot: true})` — folders and the collection root included — and merges what it finds. ## What that means in a large shared collection When a collection is edited by several people over months, the three models produce different kinds of surprise, and the mitigations differ: - A behaviour member added to a **folder** changes every entry in that subtree silently. Nothing in a request shows that it inherited a changed switch; only the resolver's output does. - A behaviour member added to a **request** is invisible from the folder above it, which is exactly the case that produces *one endpoint behaves differently and nobody knows why*. - Adding a script to a folder **adds work** to every entry below rather than replacing anything, so its symptom is extra behaviour, not changed behaviour. - Changing a credential declaration replaces what an entry was using, so its symptom is a failing call rather than a subtly different one. Practical habits that follow: 1. Keep behaviour switches as a **root house rule** with a small, deliberate set of exceptions, rather than sprinkling them across entries. 2. When one entry misbehaves, ask **which level supplied each member** rather than reading only the entry's own block. 3. In review, treat a new folder-level behaviour member as a change to every entry in the subtree, because that is what it is. 4. Do not reason about one surface using another's rule — *the folder script overrode mine* and *the folder behaviour stacked with mine* are both wrong sentences. ## Where the boundary sits This comparison is about **inheritance shape**, not about the other surfaces' internals: how credentials are declared and how the nearest declaration is located, and how inherited scripts are ordered and which one owns a given execution, belong to their own topics and should be cited rather than explained. Likewise, what any given switch does on the wire — following a redirect, checking a certificate, cookie attribute meanings — belongs to the HTTP, TLS and cookie topics. The claim this field owns is narrower and worth stating exactly: **`protocolProfileBehavior` is the collection's third inheritance surface, and it merges member by member with the nearest declaration winning.** ## Mistakes to avoid - Assuming one inheritance rule covers everything a collection declares. - Describing behaviour members as stacking, or scripts as resolving to one. - Saying a request-level behaviour block discards the whole inherited block. - Treating a folder-level switch as documentation of what an entry does, rather than an invisible change to the subtree.