Designing roles and permissions in business applications

Roles and permissions

• Permissions are specific rights: view orders, edit prices, approve discounts, export data, manage users.
• Roles group permissions for a job: sales manager, warehouse operator, accountant, administrator.

Users are assigned roles; roles carry permissions. This keeps administration manageable as the team grows.

Scope: which data

Permissions answer "what can I do?"; scope answers "to which records?":

• a sales manager sees their own clients, a head of sales sees the whole team's;
• a branch manager sees their branch;
• a client in a portal sees only their company's data;
• a SaaS customer's users see only their organisation's data. See multi-tenancy.

Scope rules must be applied in every query on the server. Many data leaks happen because an application checks whether a user can view orders, but not whose orders.

Designing from jobs

1. List the people who will use the system and what they do daily.
2. For each task, note the data and actions it requires.
3. Group into roles; check for overlaps and gaps.
4. Identify sensitive actions — deleting records, changing prices, exporting personal data, refunds — and restrict them.
5. Decide who administers users and roles.

Delegation and client-side administration

In portals and B2B products, clients often need to manage their own users: add a colleague, remove someone who left, change permissions within limits. A client administrator role with limited rights reduces work for your team and keeps access current. See customer portals.

Approvals

Some actions need a second person: large discounts, refunds above a threshold, publishing content. Approval workflows combine permissions with process: one role creates, another approves.

Audit logs

Record who did what and when for sensitive data and actions: changes to prices, statuses, permissions, exports and deletions. Logs help resolve disputes, detect misuse and meet data protection expectations.

Common mistakes

• Only hiding UI elements: permissions must be checked on the server for every request.
• Too many custom roles: every user with a personal set of rights becomes unmanageable.
• Shared accounts: several people using one login make audit logs meaningless.
• Forgotten access: former employees and contractors who still have accounts. See access management for teams.
• Admin for everyone: convenient at first, dangerous later.

Testing permissions

Test each role with realistic scenarios, including attempts to access other users' or clients' data by changing identifiers in requests. This is a standard part of a security audit.