Org defaults vs personal share need a stated winner

What it is

Enterprise spaces often run two rulebooks: the admin’s org default (no external links, new docs only-me, guests view-only) and the personal share on this object (I need to send a link to a vendor). When they clash, people must know who wins, and whether the tap they just made actually applied. Unclear precedence produces “the UI says shared, they cannot open it,” or “I set only-me, the whole company can still search it.” This is how a policy clash is shown, not how to read an inheritance tree, and not whether widening confirms.

Why it happens

Personal settings live on the object, org policy on the tenant. If precedence exists only on the server, the UI shows the value just picked while actual grants are clipped by policy. Senders plan from the UI; recipients are refused by policy; both think the other side broke. The other way: policy wider than the person (default org-discoverable) and they think sharing is off, search still hits. The clash has to become a visible constraint at settings time: unavailable, or immediately “the org does not allow this; actual remains X,” not a successful save that fails on the other side. Precedence copy also has to say who can change it—the document author cannot edit tenant policy and should be pointed at an admin, or they will toggle the same switch forever.

Studying it

In a tenant that forbids external links, ask an author to create “anyone with the link can view.” Compare: the link control disabled with a reason, the control clickable then a silent save failure, the control looking successful while the recipient gets 403.

Independent variables: clash shown as disable-before versus fail-after, whether the winning layer (org policy) is named, whether an admin path is explained. Dependent variables: sender belief that share succeeded, bypasses (export then mail), repeats of the same setting.

If the lab author is also an admin, they will change policy and you will not measure “cannot change it.” Use a pure author account. Do not mix “they already downloaded” into this task.

Where it stops holding

Consumer products with no tenant have no such clash. Project-level policy between tenant and person needs three named layers, not a vague “admin.” When policy is wider than the personal choice (a compliance library forced org-discoverable), Only you should be unavailable, with the library as the reason. If a policy change retroactively breaks existing links, creators of those links must be told, or yesterday’s valid share dies silently and looks like a product fault.

Applying it

• Options forbidden by org policy are disabled on the share surface, with “org policy does not allow external links.” Do not let people click through to a failed save.
• Write the effective scope beside the personal pick: “you chose a link; org policy limits it to named people.”
• Explain who can change that policy. If the author cannot, do not offer a switch that looks editable.
• Verify: in a space with an external-link ban, ask someone to send a document outside. If the UI shows success and the recipient cannot open it, precedence was not stated. Ask for this object’s true scope; it must match the policy.

Related

• Within the group: H8.08.1 Current sharing scope must sit beside the content · 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
• Adjacent: V3.07 Permissions and Sharing Scope · H8.04 Copy, Share, and Export
• Search terms: sharing policy · admin override · org default