CRM user permissions control which people can view, create, edit, delete, export, or administer records. Role-based access means you assign a job role, and the role carries the permissions, instead of ticking boxes differently for every user.
A CRM that everyone can export is a contact list with extra steps. Least privilege means each person gets the access their job needs, and no standing access “just in case.”
Roles worth defining
Start with a short list:
- Salesperson — own leads and opportunities, edit own activities, read accounts they are allowed to see
- Sales manager — the same, plus the team’s pipeline and reassignment
- Marketing or inside sales — create leads, limited edit rights on accounts
- Finance or operations viewer — read customers and quotation status, no pipeline edits
- Administrator — user management, field changes, imports, and security settings
Administrator is not a reward for seniority. It is a high-risk role. Keep the count small.
Ownership and teams
Ownership answers “who is responsible.” Visibility answers “who else may look.” They are different. A salesperson can own a deal while a manager can see it. A colleague in another branch might see the account name but not the pricing notes.
Common patterns:
- Private: only the owner and managers above them
- Team: everyone in the Johor branch sees Johor accounts
- Organisation-wide read: useful for a customer master, dangerous for notes and files
Write the pattern in a table before you click through a setup screen. Products name these ideas differently. Some use roles only. Some add record-level sharing. Test with a real user login, not with the admin account you used to configure the system.
Setting access without guesswork
- List job roles and the records each job touches
- Mark view, edit, delete, and export per role
- Decide team visibility versus private deals
- Test with a non-admin user
- Review joiners, movers, and leavers on a schedule
Exports, deletes, and admin tasks
Export and delete deserve their own decision. A user who can export all contacts can walk out with the database. A user who can delete accounts can remove the only link to accounting. Prefer “deactivate” over delete, and limit export to managers or a data role.
Field changes, workflow edits, and mass update are admin work. If every salesperson can add picklist values, the pipeline stages will fork within a month.
Reviews
When someone changes branch or leaves, update the role the same day. Disable the login. Reassign open records using the same thinking as lead assignment. A quarterly check of who still has administrator rights catches old project logins.
Personal data in the CRM makes this more than neatness. Access control is part of careful handling, discussed further in CRM email logging and consent.
A practical example
A five-person sales team shares one “sales” login because it was faster during setup. Nobody can see who changed a discount. The replacement is five named users: three on a salesperson role, one manager who can see all branches, and one admin login held by operations. Export of contacts is limited to the manager. A test user confirms that a salesperson cannot open another branch’s quotation PDF.
Key takeaways
- Bind permissions to roles, then put people in roles.
- Separate ownership from visibility.
- Restrict export, delete, and admin changes.
- Review access when people join, move, or leave.
FAQ
Is a shared password acceptable for a small team?
No. You lose accountability, and you cannot remove one person without blocking everyone. Named users are the baseline.
Should interns see customer phone numbers?
Only if the job requires it, for a limited time, on the records they work. A read-all role for convenience is hard to justify later.
Do permissions replace an audit trail?
No. Permissions reduce who can act. An audit trail records what they did. See CRM activity logs and audit trails.