Setting up roles and permissions so people see only what they need

Access set person by person drifts. One clerk is given a little more to cover a holiday, nobody takes it back, and a year later nobody can say why the van driver can approve credit notes. Design access around jobs instead: write down each job, decide what it needs, and give each person the role of their job.

Most distributors need fewer jobs than they expect: sales clerk, collector, warehouse keeper, buyer, accountant, field supervisor, branch manager and owner. A person who really does two jobs gets one role built for the pair and named for it, rather than a pile of exceptions.

TipName each role after the job, such as warehouse keeper, never after a person, so it survives staff changes.

The simplest control in any company is that the person who enters a transaction is not the one who approves it. The clerk who raises a purchase order should not release it; the rep who sells on credit should not lift the customer’s credit hold; the cashier who counts the till should not approve the shift.

Treat approve as a separate level, granted only to the few who need it, and check each role for pairs of rights that should not sit together.

• Raising and approving purchase orders.
• Entering vendor bills and paying them.
• Selling on credit and releasing credit holds.
• Counting cash and approving the count.
• Changing prices and approving discounts above the ceiling.
• Creating users and granting them roles.

TipIn a small company where one person must do both, keep the right, but have the owner read a weekly list of what that person approved.

Build each role once, with the levels you agreed, then try it before anyone relies on it. Sign in as a test user with that role and walk through a normal day of that job. Every refusal you hit is a missing grant; every screen you can change but should not is a grant to remove.

1. Write the role on paper: job name and level per area.
2. Create the role and set its levels.
3. Give it to a test user and work through a day of that job.
4. Fix what was missing or too wide.
5. Assign the role to everyone in that job.
6. Keep the paper version as the record of what was agreed.

Many systems control access by hiding menus. That keeps screens tidy, but it is not protection: anyone who finds the address of a hidden page, or sends a request from outside the screen, may still get through. The rule must be checked where the data lives, on the server, every time a record is read or saved.

When you test a role, try the actions it should not do and confirm they are refused, not only that the button has gone. A screen that shows a record read-only, rather than hiding it, also tells the user why they cannot change it.