Design Permission Rules People Can Predict

Security & Access · permissions, enterprise, errors

Updated 2026-08-04

Decide whether access depends only on who someone is, or also on their situation. Role-based access control is fixed and predictable, and attribute-based rules that also weigh device, location, or time of day are safer and much harder to reason about.
Show the reason whenever access is refused. Your role does not include billing points at a fix, and You do not have permission points at a support ticket.
Say which of the conditions failed when the rule is contextual. Being denied on an unrecognized device at midnight is a completely different problem from being denied for the wrong role, and the two need different next steps.
Never hide the fact that something exists purely by omission. A user who can see a page in one context and not another concludes the product is broken rather than that a rule applied.
Give every refusal a route forward:

Show the effective permissions for a person, not just their assigned role. Once rules stack, nobody can compute the result in their head, and an admin needs to see the answer.
Let an admin test as another user. It is the only reliable way to answer "why can they not see this" without guessing.
Keep the vocabulary stable across the product. A permission called one thing in settings and another in an error message reads as two unrelated systems.

A permission system is only usable if a person can predict its answer before they act, and explain its answer after it refuses.