Current sharing scope must sit beside the content

What it is

Who a piece of content is open to right now is its sharing scope: only me, named people, anyone with the link, the whole team, the internet. That scope has to sit beside the content—under the title, in the toolbar, on the cover—readable without opening settings. It answers “who can see this now.” Whether widening needs a confirm, inheritance from a folder, role split, link versus named people, revoke that cannot recall a download, and org versus personal policy all assume the current scope is already visible, and are written elsewhere.

Why it happens

People estimate scope from the path they used to open the object: a private folder implies only me. The real scope may already be “anyone in the org with the link,” left on from the last share. With no scope beside the content, the estimate has nothing to check against, and later pastes, screenshots, and meeting projections run with the wrong audience. A badge compresses scope into a scannable phrase (“Only you,” “Team can view,” “Public on the internet”) that can stop the next act while the eyes are still on the title. Scope inside a settings modal is absent: people open the object to work, not to inspect sharing every time. A lock icon without words makes public and team-internal look like the same “it opens.”

Studying it

Give one document two scopes (only me / discoverable in the org), with or without a badge beside the content. Ask who can open it now, then have them send the link to a colleague in a scenario.

Independent variables: whether a badge stays by the title, copy grain (lock icon / a sentence), whether they can answer before opening settings. Dependent variables: scope accuracy, exposure to the wrong audience, settings opens just to check.

Starting the lab in the sharing panel spoils the test. Start from the body. In products, also log whether people who already have the object open see a change when someone else edits scope. Finding the Share button is not the same as knowing scope without pressing it.

Where it stops holding

A personal diary that never offers share can omit the badge; scope is fixed at only-me. A system-issued read-only copy (an invoice) has a process-defined audience; write “visible to the client,” not a team-doc badge. Presenter or projection modes may crop the badge; another cue (“not visible outside this room”) is needed or the room will assume it is already public. When permission does not allow listing members, the badge can still name the class (“3 specific people”) without names.

Applying it

• Keep one scope sentence by the title: “Only you,” “n specific people,” “anyone with the link,” “discoverable in the org,” “public on the internet.”
• When someone else changes scope, people who already have the object open see the badge update, not the value from open time.
• The badge may open settings; settings must not be required to know the scope.
• Verify: without opening the sharing panel, ask who can open this. Wrong answers, or answers only after opening settings, mean it was not visible. Change scope from another account and see whether the original window’s badge follows.

Related

• Within the group: H8.08.2 Widening access needs an explicit confirm · H8.08.3 Permission inheritance must be understandable · H8.08.4 View, comment, and edit roles follow least privilege · H8.08.5 Link sharing spreads farther than named people · H8.08.6 Revoking access cannot recall copies already taken · H8.08.7 Org defaults vs personal share need a stated winner
• Adjacent: H8.04 Copy, Share, and Export · V3.07 Permissions and Sharing Scope
• Search terms: sharing scope · access badge · who can see