Roles and Permissions: Getting Access Control Right
How to design roles in business software so staff see what they need and nothing else — including the approval limits and audit trail that protect everyone.
Who can see what, and who approves itFIG.01
Short answer
Design roles from the organisation chart, then define four things for each: what it can see, what it can create or edit, what it can approve and up to what value, and what it can export. The person who performs a transaction should not be the person who approves it, and every change needs an audit trail.
Key takeaways
- Roles follow the organisation chart — inventing roles per person defeats the purpose.
- A role definition covers visibility, editing, approval limits and export rights.
- Separating doing from approving protects the business and the employee equally.
- Review access whenever someone changes role, not only when they leave.
Access control is usually treated as an afterthought and then discovered to be the most sensitive part of a business system. Everyone having full access is a risk. Everyone needing permission for everything is a bottleneck. The design decides which problem you get.
Design roles from the organisation chart
Start with the jobs people do, not the screens in the software: order booker, storekeeper, accountant, branch manager, owner. For each, list what they must see, what they may change, and what they must approve. That table becomes the permission model.
Four things a role definition should cover
- Visibility — which records, and often which branch or project.
- Actions — create, edit, cancel, approve, export.
- Limits — the discount, credit or payment value above which approval is required.
- Sensitive fields — costing and margins are commonly hidden from sales roles.
Separate the person who does from the person who approves
The same user should not be able to create a supplier, raise a purchase order to that supplier and approve the payment. Splitting those steps is the single most valuable control in any business system, and it costs nothing to design in from the start.
An audit trail protects staff too
A log of who changed what, and when, is usually sold as fraud prevention. In practice its most common use is settling an honest disagreement in seconds. Make it immutable, and make cancellations visible rather than deleting records.
Review access when people move
Permissions granted for a temporary reason are rarely removed. Review roles when someone changes job or leaves, and keep a list of who has administrator rights — it is always longer than management expects. The wider practices are in business software security basics.
If everyone in your business currently sees everything, let us design roles around your actual approval chain.
Frequently asked questions
Can one person have more than one role?
Yes, and in smaller teams they must. Keep the incompatible combinations — creating and approving the same transaction — blocked even then.
Should salespeople see product cost?
Usually not. Give them the approved price list and a discount limit, with anything beyond it routed for approval.
Can we restrict data export?
Yes, and you should for sensitive lists such as full customer databases and price files. Export can be limited by role and logged when used.
/Services in this article
Keep reading
All articlesSecuring Business Software: Access, Backups and Audit Trails
The security basics every business system needs — authentication, least privilege, encrypted backups, tested restores and logging — explained without jargon.
What Custom Software Costs After Launch
The ongoing costs of owning business software — hosting, support, monitoring, improvements — and how to budget for them instead of being surprised.