Permission Design: Who Can View, Who Can Edit, Who Can Delete

When a system first launches, the team is small, so everyone shares one admin account — see everything, change everything, convenient. Six months later the problems arrive: a price got changed and nobody knows by whom; a part-timer accidentally deleted a whole batch of products; a former employee's phone is still logged into the back office. Permission design answers three questions — who can view, who can edit, who can delete — and it's best answered early in system design, because retrofitting permissions costs far more than building them in.

Draw the Role-Permission Matrix Before Writing Code

The first step of permission design isn't technical — it's a table. Down the side, the roles in your system (owner, store manager, staff, accountant, part-timer); across the top, the functions (view orders, change prices, refund, export reports, delete data); in each cell, "view / edit / hidden." This is the role-permission matrix, and filling it in forces decisions you've never consciously made: can staff see cost prices? Up to what amount can a store manager refund? Does the accountant need to edit orders, or only view them?

We run our own inventory-management SaaS serving a franchise network, where this table matters even more — a franchisee can see their own store's revenue but not other stores'; headquarters sees network-wide reports but delegates daily operations to the stores. In chain and franchise scenarios, permissions are fundamentally two dimensions: data scope plus function switches — not just "can they use the refund function," but "which stores' orders can they refund." Think this layer through and the system can support the organization as it grows.

Least Privilege: Deny by Default, Grant on Demand

Security has a core concept called the principle of least privilege: everyone gets only the minimum access their job requires, nothing extra. It sounds obvious, but in practice people do the opposite — "open everything first, close it if there's a problem" — because granting access requires someone to ask, while revoking it requires someone to remember. The result: permissions only ever grow, and three years later nobody can say who can do what.

The pragmatic rules:

• Manage people through roles, not one by one. A new staff member gets assigned the "staff" role, done; to change what staff can do, edit the role once and it applies everywhere. Systems configured per-person always end up as spaghetti nobody dares touch.
• Pull high-risk operations out separately. Deleting data, batch price changes, exporting the full customer list, refunds — even when a role has the permission, these actions deserve an extra confirmation, or restriction to a very small set of people.
• Offboarding must include accounts. On HR's departure checklist, "disable system accounts" should happen the same day the access card is returned. It's the cheapest — and most commonly skipped — security measure there is.
• Audit regularly. Spend half an hour each quarter on the account list: is this person still employed? Do they still need this access?

The point of permission design isn't keeping out thieves — it's making sure everyone's knife is exactly sharp enough to cut their own food. The chances of anyone getting hurt drop naturally.

Handling Exceptions: Make Permissions Too Rigid and People Route Around Them

Permission design has a paradox: make it too strict and the front line becomes less safe, not more. The store manager is suddenly out, nobody can press the refund button, so everyone starts sharing the manager's password — and the permission system might as well not exist. So design legitimate exception channels in advance: a delegation mechanism (the manager authorizes a deputy while on leave — time-boxed, logged) and temporary elevation (requires a supervisor's approval, leaves a trail). Make the right path easy, and people won't take the wrong one — the same principle we apply to back-office UX.

Also: permissions and logs are a pair. Controlling "who can act" isn't enough — you also need a record of "who acted." For sensitive operations like price changes and order deletions, the system should record the operator, the timestamp, and the before-and-after values. That topic deserves its own article, and we wrote it: audit logs and operation records. Permissions decide who the door opens for; logs tell you who walked through it. You need both, or there's nothing to investigate when something goes wrong.

If your system is still in the "one account rules them all" stage — or the permissions have grown so tangled that nobody dares clean them up — this is one of the most common findings in our system health checks. See our custom systems and SaaS services; the role matrix is a table we'll happily draw with you.