Every business application eventually faces the same questions: who can see salaries? Who can approve a discount above ten percent? Can a branch manager in Pune see Chennai's customers? Should a technician see the price of the parts they use? Can a dealer see other dealers' orders? Role-based access control answers these questions in a structured way. Designed well, it protects sensitive information, prevents mistakes and fraud, and keeps screens simple for each user. Designed badly, it either exposes too much or blocks people from doing their jobs.
Three questions behind every permission
- What can the user do? View, create, edit, delete, approve, export — per type of record or screen.
- On which data? All records, their branch, their team, their own records, or specific customers.
- Within what limits? Amounts, discount percentages, credit limits, date ranges.
Keeping these three separate makes the design far simpler. A "branch manager" role defines what a branch manager can do; their scope defines which branch; limits define how far they can go.
Roles, not people
Start by listing real responsibilities, not names: sales executive, sales manager, service coordinator, technician, store keeper, accounts executive, plant manager, director. For each role, list the screens and actions they need. Assign users to one or more roles. When someone changes jobs, change their role — not dozens of individual settings.
Resist creating a new role for every person who asks for something slightly different. If a request is reasonable for everyone in that position, change the role. If it is truly individual, record it as a time-limited exception.
Data scope
Most real-world access rules are about data, not screens. Common scopes include:
- Own records — a salesperson sees their leads and customers; a technician sees their jobs.
- Team — a supervisor sees their team's records.
- Branch or region — a branch manager sees everything in their branch.
- Department — HR data visible only to HR.
- Customer or partner — external users see only their organisation's data.
- Everything — management and administrators.
Scope must be enforced in the system's back-end, not just by hiding menu items. Hidden buttons do not stop someone from opening a link or calling an API directly.
Sensitive fields
Sometimes a user should see a record but not every field: cost prices and margins hidden from technicians and some sales staff, salaries hidden from managers outside HR, customer contact details hidden from subcontractors, bank details visible only to accounts. Field-level rules should be few and clear, applied consistently on screens, reports and exports.
Approvals and limits
Permissions often depend on amounts: a sales executive can give up to five percent discount, a manager up to ten, a director beyond that. Purchase orders, credit notes, write-offs and refunds follow similar patterns. Build these limits into roles and route anything above the limit for approval, with a record of who approved what.
Segregation of duties
For financial and inventory processes, the same person should not be able to complete every step alone: creating a supplier and approving payments to them, raising and approving their own purchase request, adjusting stock and approving the adjustment. Identify these conflicts and design roles so they need two people.
External users
Customer portals, dealer apps and subcontractor access introduce users outside your company. Give them separate roles with strict scope — their own orders, jobs, equipment, invoices and documents only. Review what each screen shows: an internal note, a cost price or another customer's name appearing in an external view is a serious problem.
Administrators
Limit full administrator access to very few people. Administrators who manage users and roles do not necessarily need access to all business data. Log every change to users, roles and permissions.
Audit logs
Record who created, changed, approved, exported or deleted important records, and when. Audit logs answer disputes quickly, deter misuse and help investigate mistakes. They should be readable by authorised managers, not only by developers.
Joiners, movers and leavers
- Joiners — new users get roles based on their position, approved by their manager.
- Movers — when someone changes position or branch, their roles and scope change on the same day; old access is removed.
- Leavers — accounts are deactivated immediately, open work is reassigned and history is kept.
Shared logins should be avoided: they make audit logs meaningless and cannot be revoked for one person.
Reviewing access
Access tends to grow over time as people collect permissions. Review users and roles at least twice a year: who has administrator access, who has access to sensitive data, which accounts have not logged in for months, and whether exceptions are still needed. A simple report of users by role and scope makes the review quick.
Designing access in a new project
- List roles and their responsibilities.
- Create a matrix of screens and actions against roles.
- Define data scopes and sensitive fields.
- Define approval limits and segregation rules.
- Test with realistic users — including checking what each role must not see.
Including access design in the requirements, rather than adding it at the end, avoids painful rework.
Example
A multi-branch service company's system gave every coordinator access to all branches' customers and every technician access to parts costs. After a coordinator who left took customer lists to a competitor, the company redesigned access: roles by position, data scoped by branch, cost fields hidden from technicians, exports limited to managers and logged, and immediate deactivation on exit. Screens became simpler for most users, and managers could see exactly who had accessed and exported what.
Summary
Good access control separates what users can do, on which data and within what limits. Assign permissions to roles, enforce data scope on the server, protect sensitive fields, build approval limits and segregation of duties, keep external users strictly contained, log important actions and review access regularly.
Frequently asked questions
Should permissions be given to roles or to individual users?
To roles, almost always. Users are assigned one or more roles. Individual exceptions should be rare, recorded and reviewed, or they quickly become impossible to manage.
How many roles should a business app have?
As few as possible to reflect real responsibilities — often between five and fifteen for a mid-sized business system. Dozens of roles usually means permissions are being designed person by person.
Can a user have different access in different branches?
Yes. A well-designed system separates what a user can do (role) from which data they can do it on (scope), such as branches, regions, departments or customers.
How do we handle staff who leave?
Deactivate their account immediately, transfer their open records to someone else, and keep their history intact. Never delete users who have created records.
Do customers and partners need separate roles?
Yes. External users should have their own roles that limit them strictly to their own data — their orders, jobs, equipment or invoices — with no access to internal screens.
