Nearly every system starts with roles. Admin, manager, operator, maybe read-only. It is a good first model — it is legible, it fits in a dropdown, and it answers most questions for a single-site business.

Then you open a second location, and the model stops describing reality.

What actually gets asked for

The requests arrive one at a time and each sounds reasonable on its own.

  • The branch manager should see their branch, not the others.
  • The regional manager should see four branches, but only one of the two brands.
  • The accountant should see everything, but for one legal entity only.
  • Head office should see everything, except customers' phone numbers.
  • The partner should see their own orders and nothing else at all.

None of these is a role. Each is a combination of dimensions — location, brand, legal entity, and what kind of access — and roles cannot express combinations without multiplying: manager-north-brand-a, manager-north-brand-b, and onward until nobody can say who can see what.

Scopes instead

The model that survives is a scope: a set of grants along each dimension, with read and read-write as separate levels, where read-write implies read. A user is not "a manager". A user has read-write on two branches, read on a third, and no access to the fourth.

That sounds like more work, and at the start it is. What it buys you is that the fifth request — the one nobody predicted — is a configuration change instead of a release.

In the platform this comes from, access resolves across brand, branch, city and legal entity simultaneously, and the working context a user picks at the start of a shift determines what they are creating records against for the rest of it.

Personal data deserves its own switch

Somebody needs to look up an order without being entitled to the customer's phone number. Somebody in a clinical setting needs to see a schedule without seeing diagnoses.

Treating personal or medical data as a separate permission — rather than as a consequence of seniority — is both the right thing and, in most jurisdictions, the required one. It has a design consequence worth knowing: masking beats hiding. Show a phone number with its last two digits and everything else starred out, rather than an empty field, because the user still needs to recognise the record they are looking at. An empty field looks like missing data and generates a support ticket; a masked one explains itself.

The part everybody underestimates

Scopes are not a login feature. They are a filter on every query in the system, a condition on every write, and a rule inside every report and export. Miss one report and you have a data leak that nobody notices for months.

This is why retrofitting is so expensive, and why it is worth asking the question at the start even if the answer today is "one location, four people". The question is not how many locations you have. It is whether you intend to have more than one — and, separately, whether you will ever have a second legal entity, because that one catches people out.

If your business is heading that way, it is much cheaper to be told now. Send us the shape of your organisation — branches, brands, entities, who must not see what — and we will tell you whether you need scopes yet, or whether three roles will genuinely see you through another two years.