Permissions: deciding who sees what, and why

Permissions get set once, during setup, by somebody guessing at jobs that do not exist yet. Then reality arrives.

Somebody cannot see a table they need, an admin widens the role, and six months later everybody can read everything.

Start from the job, not from the data

Asking who should see the wages table produces an argument. Asking what a shift supervisor does each day produces a list.

The job gets written down first, and the grant follows it. A permission set built this way explains itself to the next person who reads it.

A few fields need restricting, and most do not

Blanket restriction is what makes people ask for more access. Most fields on most tables are ordinary and hurt nobody.

The short list usually covers pay, bank details, personal contact details, and anything commercially sensitive. Those few need restricting, and the rest stays open.

A field somebody cannot see stays hidden everywhere, including in the notifications about that record. Our guide to record history covers why the history follows the same rule.

Teams beat individual grants

Permissions granted person by person drift within a month. Somebody leaves, somebody covers, and nobody unwinds the temporary access.

Permissions belong on a team, with people moving between teams. The leaver takes nothing with them, and the new starter arrives with the right access on day one.

Say what somebody cannot do, rather than hiding it

A control that vanishes looks like a bug. The person hunts for it, asks three colleagues, and eventually asks an admin to widen their role.

A control that appears disabled, with a line saying why, ends the hunt. Your admin then hears a real request instead of a vague complaint.

Review it when somebody changes jobs

The moment permissions drift most is a promotion or a move. Somebody gains new access and keeps the old, and nobody notices for a year.

Access deserves a review whenever somebody's job changes. That single habit removes most of the accumulated access in any business.

One admin is a risk, and so is ten

A single admin blocks the business the week they take leave. Ten admins means nobody owns the settings and everybody changes them.

Two or three suits most small businesses. Two or three named admins, known to everybody, with the list reviewed yearly.

Shared devices need their own answer

A kiosk by the door and a tablet on the counter belong to nobody. Anybody who walks past can use whatever the last person left open.

A shared device is a separate kind of account, with the narrowest access that still does its job. A check in screen needs to check people in and nothing else.

Your ordinary staff permissions do not fit here, because they assume one person at one screen. A shared device breaks that assumption every hour.

Somebody senior should also decide what happens when a shared device goes missing. That answer is much easier to give beforehand.

A shared device rarely needs to read history or see money. It strips back to the one job it does on the counter, and nothing else.

Your staff then use their own accounts for everything else, which keeps the record of who did what honest.

What to change first

• Each job gets written down before the first grant
• The short list of sensitive fields gets restricted, and the rest stays open
• Permissions sit on teams, with people moving between them
• A control gets disabled with a reason rather than hidden
• Access gets reviewed whenever somebody's job changes
• Two or three named admins, with the list checked yearly