Most permission problems begin with an innocent idea: ‘We’ll give this kind of person that kind of access.’ It is tidy, fast, and has the satisfying clunk of a drawer closing. It also tends to fail the moment a real person has more than one responsibility, changes teams, covers a colleague, or simply behaves like a human being rather than a row in a spreadsheet.
A sturdier approach is to test access through journeys and capabilities. In plain English: start with what someone is trying to accomplish, then verify the smallest set of permissions that makes that task possible—no more, no less. This is not glamorous. Neither is a seatbelt. Both are rather more useful when the road gets interesting.
Start with a journey, not a label
A role is a shorthand. A journey is a story. ‘Administrator’ tells you almost nothing about the exact work being done; ‘review a request, correct a record, and hand it off’ tells you where to look for friction and risk.
For each important journey, write a small scenario with a beginning, middle, and end. Keep it concrete: what is the person trying to achieve, what information should they see, what action should they be able to take, and what must remain out of reach? The final question is not pessimism. It is just how the universe keeps its filing cabinet from eating the cat.
Build a capability map
Instead of beginning with a long list of job titles, name the capabilities your product actually needs. Common examples include viewing a record, editing a record, approving a change, inviting another person, exporting data, or changing billing details. A person may need several of these; a role may bundle some of them; but the capability remains the useful unit of truth.
- Name actions in verbs: view, create, edit, approve, invite, export, manage.
- Separate access to see something from access to change it.
- Treat high-impact actions—money movement, deletion, publishing, user management—as their own capabilities.
- Make temporary or exceptional access visible and easy to remove.
Test the edges where bugs prefer to live
The happy path is necessary, but it is also where systems are most charmingly well behaved. The value is in testing the boundary conditions: a person who can view but not edit; someone whose access changes mid-journey; a delegated helper; a person with two overlapping responsibilities; an account that should lose a capability immediately.
A compact test matrix can keep this practical. For every journey, include at least one expected success and one expected refusal. If a refusal is vague, confusing, or quietly bypassable, it is telling you something useful about the design—not merely about the test.
Make refusals useful
A blocked action is not automatically a failure. Sometimes it is the system doing its job with admirable restraint. The experience matters, though. A useful refusal says what happened in ordinary language, avoids revealing sensitive information, and gives the person a sensible next step. ‘You cannot do that’ is technically accurate in the way a locked shed is technically architecture.
Where possible, show people the boundary before they collide with it. Hide or disable actions they cannot use, explain why only when it is safe to do so, and offer a route to the right owner or process. Clarity reduces support requests; mystery merely relocates them.
Keep the test set alive
Permission models drift as products grow. New features add new actions, teams change shape, and one ‘small exception’ wanders off to breed in the woods. Turn the journeys that matter most into repeatable checks. Revisit them when capabilities change, not only after an incident has already delivered its tiny brass band.
The goal is not a perfectly clever access model. It is a comprehensible one: people can do the work they are meant to do, they cannot quietly do the work they are not, and everyone can explain why. That is a rare form of calm in software—and worth cultivating.
Final takeaway
Test permissions through the real journeys people take and the capabilities they need. Roles are useful labels; journeys reveal whether the doors actually lead anywhere.
