Designing role-based access for tenant teams

The most common permission model in a small, growing business isn't really a model at all: everyone gets the same access, because setting up anything more granular felt like a project nobody had time for. It works until the business has staff whose mistakes - or whose access, if an account is compromised - can actually cost something.

Good role design isn't about locking things down for its own sake. It's what lets an owner actually delegate work, because they trust the boundaries around it.

Start from the job, not from a permission list

The mistake most permission systems make is starting from a list of actions - "can view reports," "can edit prices," "can process refunds" - and asking an owner to assemble a role from scratch. That's a lot of decisions for someone who isn't a systems administrator, and it tends to end with either "give them everything" or a role so restrictive the person can't do their actual job.

The better starting point is the job itself: what does a cashier need to do, versus a branch manager, versus an accountant, versus someone in procurement? Each of those is a real, recognizable role with a bounded set of things it should be able to do - and defining access around the job, not around an abstract permission list, is what makes the model something an owner can actually reason about.

Branch scope is a second dimension, not an afterthought

Role defines what someone can do. Branch access defines where they can do it. A cashier role should behave the same way at every branch, but a specific cashier should usually only be able to act at the branch they actually work at - all branches, selected branches, or none, applied consistently across list views, reports, and POS.

Treating these as two separate dimensions - role and branch scope - rather than collapsing them into one giant permission matrix is what keeps the model understandable as a business adds branches. A five-branch business shouldn't need five times as many roles; it needs the same roles, scoped differently per person.

Why this makes audits easier, not harder

A properly scoped role model has a useful side effect: when something needs auditing - a discrepancy, a dispute, an unexpected discount - the question "who could have done this" has a short, real answer instead of "everyone, technically." Combined with an audit trail that records who changed what and when, role-based access turns "we're not sure what happened" into a traceable question with a traceable answer.

That's not a compliance checkbox. It's the difference between a dispute that takes five minutes to resolve and one that takes a week of guessing.

Where teams usually get this wrong

Two mistakes show up repeatedly:

Over-provisioning at setup, "to save time." Giving a new hire full access because defining their actual role feels like extra work, with a plan to "tighten it later," is exactly how over-provisioning becomes permanent. Later rarely comes.

Treating "admin" as the only alternative to "no access." A binary model - admin or nothing - forces every delegation decision into an all-or-nothing choice, which is precisely the situation that makes owners reluctant to delegate at all. A real role model with several defined levels between those two extremes is what actually enables delegation, because the owner isn't choosing between total trust and total control.

The actual test of a good permission model

A role-based access model is working if an owner can onboard a new employee, assign them a role that matches their actual job, and not think about it again - confident that the boundaries are already correct, not hoping they remembered to tighten something manually. That's the real measure: not how granular the permission list is, but how little an owner has to think about it once it's set up right.