Staff permissions by role: set them up once and stop them creeping

Ask your software who can see every customer's details, change prices, delete records and export data. Then write the list you would have given from memory. The difference between the two lists is the job.

Staff permissions rarely go wrong in one decision. They grow through exceptions, each of which seemed reasonable on the day it was granted. Setting permissions by role instead of by person is what stops that.

Start from what each job has to do

Write down the jobs, not the people. For each job, list what it has to see and, separately, what it has to change. Plenty of jobs need to read records they should never edit.

• Front counter: sees customers and bookings, creates bookings, never sees margins or payroll.
• Bookkeeper: sees and changes invoices and payments, exports reports, has no access to staff files.
• Manager: everything the front counter has, plus approving timesheets and editing the roster.
• Administrator: settings, billing and who has access. Nothing about the day's work needs this.

Give deleting its own line. Most jobs that create records never need to delete one, and a deleted record is far harder to trace than an edited one.

Begin with three to five roles. Add another only when a real job does not fit any of them.

Two ways staff permissions go wrong at the start

A role for every variation

Manager, then Manager North, then Manager North Weekends. Roles named after every difference multiply until nobody can say what any of them allows. Keep roles at the level of the job, and handle the difference some other way, such as the team or location a person belongs to.

One role that does everything

The opposite mistake is one broad role given to anyone who needs any part of it. It looks tidy, and it gives the newest casual the same reach as the manager.

Five ways access creeps in

1. A change of job. Someone moves from the counter to the books and keeps both. Remove the old role the day the new one starts.
2. A one-off exception. Somebody needs one export and gets export rights for good. Give it to the role that should have it, or take it back afterwards.
3. A shared login. Made to get past an urgent problem, still in use months later, with no way to tell who did what.
4. The administrator's own account. Daily work done under full rights means every slip is made with full rights. Keep a separate everyday login.
5. Contractors. Access granted for a project and still active after it. Set an end date when you grant it.

Test a role before you hand it out

Before giving anyone a new role, sign in as that role, or preview it if your software lets you, and try the things it must not do: open payroll, change a price, export the customer list. A permission nobody has tried is a guess.

Try the things it must do as well. A role that cannot finish its own job gets widened in a hurry on a busy day, and a hurried change is how one broad role starts.

When someone leaves

Remove their access on their last day, not when somebody notices. Then deal with what they could reach that others still use: a shared password to change, a supplier portal login, a report they had scheduled to send to themselves.

Keep those steps as a written checklist used every time, so removing access does not depend on who happens to remember it.

Review it on a timetable

Once a quarter, list who holds each role and read it with someone who knows the business. For each person ask one question: would you give them this access if they asked for it today?

Every no is a change to make that day. Any access given to a person directly, outside their role, gets moved into a role or removed. Left alone, those one-off grants become the real permission system, and nobody has a list of it.