Permissions start with the org chart, not the screen

When permissions come up, the first question asked is almost always which screens each role should see. It is a reasonable question and it arrives too late. It assumes the roles are already known, and that is the part that needs the work.

The question that comes before it is who actually decides what in this business today, without any system at all. The answer is rarely arranged by seniority. It is arranged by who is responsible for which specific thing.

A role is not a rank

We built Mishmar a duty-scheduling system for an organisation with a real hierarchy. It has four administrative levels (superUser, branchManager, commandCenter, centerManager) and, alongside them, team commanders, who are not a level at all but a responsibility for one specific group of people.

The organisation itself is three layers: branch, section, team. The permissions derive from that. A team commander does not see less than a branch manager, they see something else: their own people. That difference gets lost when permissions are imagined as a ladder.

Build the ladder and eventually somebody needs one thing that lives a rung above them. Then you either promote them and hand over everything else too, or you add an exception. Both are bad.

A permission can come from state, not only from a role

This is the less intuitive part and, to us, the more interesting one. In the system we built for WinWin, permission to log in at all does not derive from a role. It derives from the candidate's status in the process: only an approved candidate can sign in and upload documents.

There is no "approved candidate" role there. There is a status field, and the status is what decides. In practice that means someone's permissions change as they move through the process, without anyone touching a settings page.

When is that right? When the permission is the result of a process. A candidate who was approved, a customer who paid, a supplier who signed. In those cases, managing it as a separate role means maintaining by hand what the data can already tell you.

Three levels usually covers it

That same WinWin system has exactly three administrative levels: view, edit, and full management. That covers almost every small business. View for the people who need to know, edit for the people doing the work, and management for whoever is also responsible for who gets in.

The third is the one that matters. Being able to grant access to other people is a permission in its own right, and in plenty of systems it goes unmodelled, at which point everybody is a superUser.

And when there is exactly one person

This cuts the other way too. The content editor on this site serves one user, and we gave it the simplest permission available: a single property on the user in the auth service, which the database checks on every write.

We considered an admin table with levels, and rejected it. A table like that needs its own grants, its own security policy, and a helper function to avoid a recursion loop. Three moving parts to authorise one person. The day there is a second editor the table becomes the right answer, and that will be a decision rather than a drift.

What to work out before building

Three questions, in this order. Who is responsible for what today. Which permissions are the result of a process rather than a job title. And who grants access to other people. If the answer to the third is "everyone", you do not have permissions, you have a menu.

The idea that a status is data that drives things rather than a label runs through lead management too. We wrote about it in a spreadsheet holds a list, a system holds a process.

A system whose permissions match how your business actually works