The understandability of permission inheritance and exceptions

What it is

Permissions in collaboration systems are almost never set person-by-person, document-by-document; they inherit along structure: a folder's grants pass to every document inside, a group's grants pass to every member, children default to their parent. Inheritance makes large-scale authorization possible, but the price is that "what can this person actually do to this document" stops being a directly visible value and becomes a quantity that must be derived — which folder it sits in, which groups it hits, whether an individually set exception interrupts the chain. Understandability lives or dies here: users derive the effective permission with a mental model, and wherever the model's rules diverge from the system's merge rules, the derivation comes out wrong. Two characteristic failures follow: believing an exception blocks someone's access while a deeper group nesting slips around it; believing a child document inherited a loosened right while the parent was long since tightened.

Why it happens

Inheritance compresses configuration from "write it out per object" to "one structure plus a few exceptions"; the scale win is paid for in derivation cost. The effective permission merges several sources: structural inheritance (parent to child), group expansion (a person gains access via group membership), and direct grants and exceptions (individually opened up or blocked for a specific person). What semantics govern the merge — explicit deny overriding every allow, the more specific rule overriding the more general, or the most permissive winning — varies system to system and is almost never explained to users. Users' default intuitive model is roughly "what I granted directly counts" plus "the structure I can see is all there is," and both halves can conflict with the implementation: once exceptions multiply, the cheap verification path of "read the structure, infer the permission" collapses; nested groups expanded two levels deep push the intermediate sources past working memory; and an exception quietly set on a child object is invisible from the parent's view, which actively reinforces misplaced trust in the inheritance. Errors thus accumulate silently: nobody "mis-operates" — every individual derivation is just slightly off.

Studying it

• Mental-model elicitation: given a structure (inheritance tree plus exceptions), have users select which sources compose a person's effective permission, and compare against the system's actual merge; classify errors by type — missed exception, skipped nesting level, misunderstood merge semantics — so the error distribution names the hardest rule.
• Prediction tasks: with a structure diagram, have users predict effective permissions item by item for a set of (person, document) pairs against ground truth; where errors cluster (depth, exception count, source count) quantifies the collapse point of understandability.
• Derivation time: record prediction latency as nesting depth and source count grow; a steep jump marks the boundary past working memory.

Where it stops holding

Inheritance remains the right default — a few people and one level of structure almost never go wrong; trouble erupts only under deep nesting and multi-source stacking (groups inside groups, direct grants coexisting with link grants). The opposite extreme, fully flat permissions (every document configured individually), is understandable but unmaintainable and rots at scale. So the goal is not to abolish inheritance but to make the derivation inspectable: state the effective value outright, keep the sources traceable. Understandability here covers only whether the effective permission can be correctly derived from the static structure; what the tiers themselves mean (view/comment/edit), and how changes are communicated, are two further matters in this same group.

Applying it

• Put the merged effective value on the first line of the permission panel (what this person can actually do to this document), with the source list folded beneath — result first, composition on demand.
• Make the effective value traceable to its sources: expanding it lists "inherited from which folder, via which group, which exception," each jumping to the origin for editing.
• Flag objects carrying exceptions in structure and list views, and show "N exceptions below" from the parent's view, so exceptions stop being invisible.
• Unify merge semantics system-wide (e.g., explicit deny wins) and document it; no feature may quietly run its own variant.
• Suggest simplification when groups nest past two levels or sources stack past three — treat structural complexity as a managed design metric.
• Verification: after changing a parent's permission, walk the propagation and check it matches user expectation; regression-test permission UI redesigns with the prediction task — passing means error rates did not rise.

Related

• Same group: V3.07.1 Sharing scope must be persistently visible next to the content · V3.07.2 The semantic difference between view, comment, and edit permissions · V3.07.3 Expanding the sharing scope requires explicit confirmation · V3.07.5 Permission changes must notify affected collaborators
• Nearby: A7 Mental Models · V7.04 Content Governance
• Search terms: permission inheritance · effective permission · access control list · exception override