When a new salesperson starts, permissions are copied from the previous person's screen. After a few months, no one knows who sees what or why.
User-based permission is fast in the short term, but as you grow, it becomes unmonitored. The sustainable way is to go through role templates.
In this article, we explained role-based authorization, template design, module and action separation, and ease of handover.
Table of Contents
Why roles instead of individuals?
Permissions specific to a person remain like an inheritance when they leave and accumulate. A role, however, is tied to the job description and transfers cleanly when the person changes.
EQLEM is a solution platform; the authorization model must also be scalable. Copy-paste that manages with ten users collapses with a hundred users.
A role gives the same visibility to everyone doing the same job. This equality also reduces training and support burdens.
The question asked during an audit is directed at the role rather than the person; which job needed which authority. The answer is written in the template.
We explained the basic setup in the how to set up user permissions article.
Role template design
The number of templates should be kept low; creating a separate role for each person reverts to the individual-based model. Five to ten main roles are enough for most businesses.
Names should be in business terms; such as Sales Representative, Warehouse Supervisor, Accounting Approval. Technical code names alienate the team.
In every template, viewing, creating, editing, and deleting are considered separately. Open-by-default for all of them poses a risk.
Template changes are reflected for all assigned users; therefore, modifications must be done with change control. A sudden expansion of permissions quietly opens up risk.
Align the department structure with the employee definitions article.
Module access
The role determines which modules can be seen first; a closed module does not take up space in the menu. This also reduces the license and training burden.
A sales role does not need to enter the finance module. Unnecessary menus increase the risk of erroneous operations.
Module access and transaction permission are different; seeing is not changing. Do not lump the two together in the same box.
Roles must be reviewed when a new module is opened. Automatically granting full permissions is dangerous.
Consider module selection along with which module to start with article.
Transaction permission separation
Viewing the list, creating a record, approving, and deleting are separate permissions. Deleting, in particular, is the permission that should be kept the narrowest.
In transactions requiring approval, the creator and the approver must be separated. The same person performing both steps destroys control.
Areas such as price changing, discount upper limits, and credit limits require separate permissions. General editing authority does not cover these.
The permission matrix must be kept in writing and reviewed periodically. Old permissions accumulate silently.
We elaborated on sensitive areas in the sensitive transaction permissions article.
Scope versus authority
The role dictates what can be done, while the scope dictates what can be seen. If the two do not work together, either everything is visible or nothing is.
A branch manager should only see their own branch. A holding executive, on the other hand, needs a consolidated view.
Warehouse scope is critical in stock movements; incorrect warehouse visibility produces wrong shipments. Test the scope with the record context.
In multi-company structures, the company scope is added to the role. Incorrect company records create financial irregularities.
We explained the scope model in the branch and warehouse scope article.
Handover and onboarding
Assigning a role to a new user takes minutes; setting up custom permissions takes hours. This speed also improves the onboarding experience.
The departing user's account must be closed, but the role template should remain. Clearing permissions without deleting the account is not enough.
A separate short-term role can be used for temporary proxy. Granting proxy without breaking the permanent template is safer.
The handover checklist must be written; access, device, and notification preferences are closed together. Forgotten mobile sessions leave risks.
We covered audit logs in the user message logs article.
Audit trail
Authorization changes must be traceable; who gave which role and when must be known. Silent permission expansion is one of the most expensive risks.
Transaction logs must also be kept for sensitive operations. Deletion and approval records are especially critical.
Periodic permission reviews should be made routine. Checking the role-user mapping once every three months is sufficient.
Report access is also an audit matter; not everyone should see financial reports. Manage report permissions separately.
We elaborated on report confidentiality in the report permissions article.
Sensitive roles
Finance, e-document, and system administration require separate sensitive roles. Do not pile these into a general admin role.
The number of super users should be kept as low as possible. If everyone is an admin, no one is an admin.
A two-person rule can be applied for sensitive roles; critical changes require secondary approval. This reduces errors and abuse.
Conflicts with permissions on the existing ERP side must be checked. Excessive permissions for the same person in both systems accumulate risk.
We clarified the platform position in the solution platform or ERP article.
Common mistakes
Giving everyone administrator access is the most frequent mistake; control is lost for the sake of speed. Start with narrow permissions and grant more as needed.
Piling extra permissions on a person without updating the role template is the second mistake. This renders the template meaningless.
Forgetting the scope and focusing only on the transaction is the third mistake. The user sees everything and posts to the wrong company.
Leaving a departed account open is the fourth mistake. Sessions and notifications continue silently.
We covered notification noise in the notification management article.
Setup steps
First, list the business roles and create five to ten templates. Then, write the module and transaction matrix for each template.
Define scope rules for company, branch, and warehouse. Test real records with a test user.
Migrate existing users to templates; clean up user-specific permissions. Cleanup is half of the setup.
Conduct a weekly permission review in the first month. Complaints are often caused by excessive scope rather than missing permissions.
Complete the initial setup checklist with the system settings article.
Frequently asked questions
Can a user be assigned multiple roles?
Yes, it is possible; however, auditing conflicting permissions becomes difficult. If possible, prefer a single main role.
Is the current session affected when a role changes?
Generally, new permissions apply to subsequent requests; it is good practice to refresh the session for critical changes.
What is its relationship with existing ERP authorizations?
Platform permissions are independent of your existing ERP system; avoid excessive permission accumulation on both sides.
How many roles are sufficient?
In most businesses, five to ten core roles are enough; do not create a custom role for every single person.
Role-based authorization is the only sustainable access model for growing teams. Cloning users is fast in the short term, but risky in the long term.
A small number of clear templates, segregation of duties, and scope rules must be established together. If one is missing, security is breached.
Segregate sensitive roles and keep the number of superusers low.
Manage onboarding and offboarding through templates; secure access is granted in minutes.
Audit permission changes; silent expansion produces the most expensive surprises.
By consulting with the EQLEM team, you can set up your role templates together.