Designing User Roles and Permissions: Least Privilege, Branch-Level Data Scope, and Handling Departing Staff Accounts

When a system first goes live, only a few people may be using the admin panel, and sharing one administrator account is the easy option. A year or two later, there are more staff, new branches, part-timers, and outsourcing partners, and the problems appear: new hires can see every customer record on day one, an order gets changed and nobody knows who did it, and a former employee’s account can still sign in. These are the results of user roles and permissions not being planned at the start.

Permission design sounds like an engineering matter, but the questions it really answers are management questions: who should see what, who can change what, who can approve what, and how to investigate when something goes wrong. An engineering team can build any rule, but the rules themselves have to be decided by the business owner.

This guide explains the difference between roles and individual grants, the principle of least privilege, how to design data scope for branches and departments, what the activity log should record, and how to handle accounts when people change jobs or leave. It ends with a permission matrix template you can use for your own inventory.

Why everyone cannot use the administrator account

Sharing a top-level account brings several real risks:

• No traceability: when data is changed by mistake or deleted, there is no way to find out who did it or when.
• Mistakes have a large impact: a new hire may press “Delete” simply because the button is visible.
• A wider data leak: if any one person’s computer or password is compromised, the whole system’s data is exposed.
• Departure risk: a shared password cannot be revoked for only the person leaving; everyone has to change it, and that is often put off.
• Internal disputes are hard to settle: in disagreements involving money or stock, without records it is one person’s word against another’s.

So the first principle of permission design is one account per person, never shared. Every other design decision builds on that. For basic security concepts overall, see Website Security Basics for Businesses.

Roles and individual grants: two ways to assign permissions

There are two basic ways to give permissions.

Role-based access: first define roles such as “store manager,” “accountant,” “customer service,” and “warehouse,” each with a set of permissions, then assign people to roles. A new hire just needs a role selected rather than ticking boxes one by one, and when a job’s permissions change, you edit the role once and everyone in it is updated.

Individual grants: tick the functions each person can use directly. It is the most flexible, but it becomes hard to manage as headcount grows, and over time nobody can explain why a particular person has a particular permission.

In practice, roles are the rule and individual grants the exception. Most people follow their role, extra permissions are added only in a few special cases, and each extra grant should have a reason and an end date. If a role keeps needing individual additions, that is a sign the role definition itself should change.

Principles for designing roles

• Name roles in the language of the job, not something like “Permission Group A” that nobody understands.
• Keep the number of roles to what is needed; too many roles make it unclear which one to assign.
• One person can hold several roles, for example store manager and buyer at once, so the system needs to support combining roles.
• Document each role, stating who it applies to and which permissions it includes.

Least privilege: just enough access

Least privilege means each person gets only the permissions needed to do their job, and no more. It is not about distrusting staff; it limits the impact of mistakes and leaks.

Splitting permissions more finely usually means distinguishing these actions:

• View: can see the data.
• Create and edit: can create or modify data.
• Delete: can delete data. This is usually stricter than editing, and many systems use “void” instead so the record is kept.
• Approve: can approve actions that need a checkpoint, such as refunds, discounts, shipments, or stock adjustments.
• Export: can download data as a file. Export is a high-risk point for leaks and is often overlooked.
• System settings: can change permissions, pricing rules, and system parameters, which should be limited to very few people.

Pay particular attention to separation of duties: the same person should not be able to both request and approve the same thing, such as raising a refund and then approving it themselves. List rules like this during the requirements phase so the system can block them in the workflow.

Data scope for branches and departments

Permissions are not only about which functions someone can use, but also which data they can see. Two store managers both have “view orders,” yet the Taipei manager should see only Taipei’s orders. That is data scope.

Common levels of data scope:

• Personal: only the data the person is responsible for, such as a salesperson seeing only their own customers.
• Department or branch: data belonging to their unit.
• Region: a regional manager sees several branches under them.
• Company-wide: headquarters managers see everything.

Situations to consider in the design:

• One person, several units: staff who cover several branches need to be assigned more than one data scope.
• Cross-unit work: when a customer of branch A shops at branch B, branch B needs the member’s essential information, but not necessarily their full history at branch A.
• Reorganization: when branches merge or regions are redrawn, data scope should be adjustable in bulk rather than account by account.
• Report scope: reports and exports must apply the same data scope. A common gap is that data hidden on screen appears in full in a report or export file.

Data scope affects how the database tables are designed, and adding it after launch often means major changes, so settle the organizational levels early when planning an internal admin system. Member data involves personal information, so scope design should also be considered together with the plan for your membership and CRM system.

A permission matrix template you can fill in tomorrow

Before talking to a development team, fill in a permission matrix. Here functions run down the rows and roles across the columns, and each cell holds the permission and its data scope. A skeleton:

Function	Store staff	Store manager	Accountant	HQ administrator
Orders	View, create (own store)	View, edit, void (own store)	View (all)	All permissions (all)
Refunds	Request (own store)	Approve (own store)	View (all)	Approve (all)
Member data	View (own store)	View, edit (own store)	Not visible	View, export (all)
Stock adjustments	Request (own store)	Approve (own store)	View (all)	Approve (all)
Reports	Not visible	View (own store)	View, export (all)	View, export (all)
Account and permission settings	Not visible	Not visible	Not visible	All permissions

Steps for filling it in:

1. List every job, merging jobs that actually do the same work.
2. List every function module in the system, including export and settings.
3. For each cell, ask: “If this job could not do this, would their work get stuck?” If the answer is no, leave it blank.
4. Mark the actions that need approval and confirm that requesting and approving are not in the same role.
5. Ask each unit’s manager to confirm their own column.

Once complete, this table is the core of your permission requirements. For writing the rest of the requirements, see How to Write Software Requirements.

Activity logs: answering “who, when, and what” when something goes wrong

Activity logs (audit logs) are the other half of permission design. However strict the permissions, someone will eventually make a mistake within their own permissions, and then the log is what you rely on.

What to record:

• Sign-in and sign-out: time, account, where the sign-in came from, and failed sign-in attempts.
• Changes to important data: who changed which field from what to what, and when, especially prices, payments, stock, and member data.
• Deletions and voids: which record was deleted and why.
• Exports: who exported data, and with what scope.
• Permission changes: who changed whose permissions to what. These records are the most often overlooked and the most important.

The log itself needs protection: ordinary staff should not be able to edit or delete it, and how long it is kept should be decided by business needs and the applicable regulations. The log must also be searchable by account, time, and record, or it is stored but impossible to find in.

Transfers and departures: the account life cycle

Account problems most often arise when people change roles. Nobody forgets to open an account when someone joins, but adjustments for transfers and departures are easily delayed.

Account handling process

• Joining: the manager submits a request, an account is opened according to the role, and the password must be changed at first sign-in.
• Transfer: remove the old job’s role and add the new one. Do not only add, or permissions pile up with every year of service.
• Unpaid leave or extended absence: disable temporarily and re-enable on return.
• Departure: disable on the last working day, not after all exit paperwork is finished.
• Regular review: at a fixed interval, have each unit’s manager confirm that the accounts and permissions under them are still correct.

Departing staff accounts should be disabled rather than deleted. Deleting breaks the link between past log entries and the person, and may affect data the account created. Keep disabled accounts for a while, then handle them according to company policy.

If the company uses business accounts from Google, Microsoft, or similar providers, consider connecting the system through single sign-on, so disabling the company account on departure removes system access at the same time and fewer things slip through. See A Guide to Social Login and SSO.

What to check before and after launch

Building permissions does not mean they were built correctly. During acceptance, actually sign in with accounts for each role and test, rather than checking with the administrator account whether features appear:

• Sign in as each role and confirm users see what they should and cannot see what they should not.
• Type in the URL of another branch’s data directly and confirm the system blocks it, rather than merely hiding the button.
• Test whether reports and exports apply the data scope.
• Confirm that disabled accounts can no longer sign in, and that existing sessions are ended as well.
• Confirm that permission changes are logged.

“Only hiding the button” is the most common gap: the option is not on screen, but anyone who knows the URL or calls the interface directly can still get in. Permission checks must always run on the server. For how to run acceptance, see How Software Acceptance Works.

Permission design costs least when done early; adding it after a system has been used for years often means touching the database tables and every function. If your admin system is about to be built, or your current system still relies on shared accounts and branches can see each other’s data, talk to NETVANA about your organization and permission needs. We first work through the permission matrix and data scope with you, then plan how the system will implement them. Software work is quoted after a consultation; what each service includes is listed in the software services overview.

Further reading: For planning an admin system as a whole, start with A Guide to Building Internal Admin Systems. For the scope and protection of member data, read Membership and CRM System Development. To unify sign-in with company accounts, see A Guide to Social Login and SSO. For basic protection of accounts and data, refer to Website Security Basics for Businesses. For acceptance testing across roles, see How Software Acceptance Works. And to turn permission rules into requirements, see How to Write Software Requirements. A knowledge base has to decide who can view and who can edit each document; see Building an Internal Knowledge Base System. Different dealers see different prices and data, so read Planning a B2B Dealer Ordering Portal.