Permission inheritance must be understandable

What it is

Content often lives in a folder, project, or space. Inheritance means people on the parent automatically get the same class of access on the child, unless this object explicitly breaks it. Understandable means someone can say “who sees this because of that folder,” and “if I turn it off here, do I also eject the parent’s people.” This is where access comes from. It is not how many role rungs exist, and not what the badge currently reads.

Why it happens

People think in objects: “I only gave Jia this document.” The system thinks in trees: the document sits in an “org can view” folder, so the org already can. When the models collide, people do null acts—remove the org on the document, save succeeds, refresh, the org is still there because the source is the parent. Without a “from folder X” label, the remove control either does nothing or quietly breaks inheritance and isolates the document from the team space, a much larger consequence than tapping an x. Breaking inheritance is a structural change and must be split from “remove this person.” The other way: changing only the parent leaves the child looking the same, and newcomers reach files that were never shared one-by-one. Deeper chains make the source harder to guess.

Studying it

Build two layers: parent folder org-visible, child document plus one extra person. Ask for every source that can open the child, and try “make the org unable to see this while it stays in the folder.”

Independent variables: whether access is grouped by source, whether break-inheritance is named as its own act, whether changing the parent notifies on the child. Dependent variables: complete source lists, “I removed them” yet they still open, accidental inheritance breaks.

A lab that draws the tree on the worksheet lets people answer from the diagram. Start from the open child, no tree first. Do not mix link-sharing into the same task.

Where it stops holding

Flat objects with no hierarchy have no inheritance; the list is the full source. OS-level ACLs are more complex than product folders; the product should explain its own tree in human language, not dump SIDs. Moving an object to a new parent changes inheritance; that is a widen or a narrow and needs a confirm by direction, not a silent parent swap. External guests who cannot open the parent still need “via project Y” on inherited access, even if they cannot open Y’s settings.

Applying it

• Group the access list by source: “added directly,” “from folder X,” “from org default.” Mark which groups can be removed at this layer.
• Make Stop inheriting its own act, with copy that parent members will no longer arrive automatically. Do not hide it as a side effect of removing one person.
• When parent access changes, open children prompt “source of access changed,” so people do not keep sending from an old roster.
• Verify: ask why people in the org can open this. If the folder source cannot be named, inheritance is not understandable. Then ask them to hide it from the org without leaving the folder, and watch for a mistaken break-inheritance or a belief that tapping x is enough.

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.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: V3.07 Permissions and Sharing Scope · H8.14 Content Lifecycle and Archiving
• Search terms: permission inheritance · broken inheritance · folder access