Designing a role and permission model that survives contact with your team

Every business system eventually asks you to define roles, and most companies answer the question badly — not through carelessness, but because the question arrives at the worst possible moment: during setup, before anyone has used the product, when the only available model is the org chart.

Roles built from the org chart do not survive. Here is a method that does.

Roles are jobs-to-be-done, not seniority

The first instinct is to make roles out of titles: Junior, Senior, Lead, Head of. This breaks immediately, because seniority does not predict what someone needs to see. A senior engineer and a junior engineer need the same screens. A team lead and an HR manager are the same seniority and share almost nothing.

The question is not “how senior is this person”. It is “what does this person do all day, and what does that require them to see”. Sort your people by that and you will usually find four to six genuine clusters, not fifteen.

Start from the smallest role and grow it

The reliable method is subtractive in intent but additive in practice: define the role that needs the least, then define each other role as that plus a named set of additions.

For a delivery organisation, that usually looks something like:

• Everyone. Their own dashboard, their own issues and epics, their own projects, their own daily report, their own attendance and leave. Nothing about anybody else.
• Delivery. Everyone, plus the project screens — board, backlog, issues, discussion, resources — and the delivery reports for the projects they are on.
• Management. Delivery, plus the cross-project views, effort and hours reporting, and the team’s daily reports and leave.
• People operations. Everyone, plus the employee directory, documents, attendance, leave administration and the hierarchy — and typically not the delivery detail.
• Business development. Everyone, plus the CRM screens — and typically not HR or project internals.
• Administration. User and role management, company settings, billing.

Notice that people operations and business development are siblings of delivery, not supersets of it. Access is not a ladder. The most common structural mistake is modelling it as one, which forces you to give a recruiter project data to give them anything at all.

The four traps

1. The role that is one person

If a role has exactly one holder and was created for them, it is not a role — it is a person-shaped exception, and it will be wrong the day they change jobs. Either the role describes a function somebody else could also do, or the difference belongs in per-object access rather than in the role.

2. Granting because refusing is awkward

Somebody asks why they cannot see a report, and it is easier to tick the box than to have the conversation. Do this six times and every role is Admin with extra steps.

The counter is to make the refusal cheap: agree up front that access is reviewed quarterly and additions are normal, so saying “not in this role, let’s look at it in the review” is a process rather than a judgement about the person.

3. Confusing role permission with object access

These are different questions. “Can this person use the board screen at all” is a role permission. “Can they see this particular project’s board” is object access.

Systems that only have the first force you into a bad choice: everyone sees every project, or you build a role per project. Matrix separates them — role permissions govern the screens, and per-project access governs which projects, so “a delivery lead who can only see their three engagements” is one role plus three access grants, not a bespoke role.

4. Believing the hidden menu item

This is the important one. A hidden navigation item is a usability feature. It is not access control, and treating it as such is how organisations end up with a permission model that is entirely decorative.

There are three places a permission has to hold: the menu (so people are not shown things they cannot use), the route (so typing the URL does not work), and the API (so a request made directly is refused). The last one is the only one that is actually security; the first two are courtesy.

When you evaluate any system, this is worth testing rather than assuming. Log in as a restricted user, find a URL they should not have, and paste it in. Then, if you can, call the endpoint directly. In Matrix all three layers read the same named permission, and the API checks independently of what the front end believes.

Write down why, not just what

The artefact worth keeping is not the permission grid — the system already stores that. It is a short document saying what each role is for: the job it describes, and the one or two things it deliberately does not include.

Without it, the next person to review access sees a list of ticks with no rationale, cannot tell an intentional exclusion from an oversight, and resolves the ambiguity by granting. That is how permission models rot: not in one decision, but in a hundred small ones made without context.

Review it on a schedule, not on an incident

Quarterly is enough for most companies. Look at three things: roles nobody holds, people whose role no longer matches what they do, and any role that has quietly grown towards Admin. Change is normal; unreviewed drift is the problem.

And keep the audit trail in view. Knowing who changed a user record, which field, from what value to what — as Matrix records for user changes — turns an access review from an archaeology exercise into reading a list.