Direct answer
Permissions follow jobs, not job titles. Two people with the same title may do different work, and one person may do three jobs. Design permissions by listing what each kind of work needs to see and change, then group those into a small number of roles. Do this on paper before you touch any settings screen. The result should be a short table your team can read. Every CRM names and structures permissions differently and offers different levels of control depending on the product and plan, so this checklist stays vendor-neutral and we make no claims about any product's exact permission model. It is part of CRM and sales workflow implementation.
Roles from real jobs
Begin with the work, not the org chart. For each activity, ask who does it, what they must see and what they must change. Typical roles emerge, though your names will differ:
- People who work leads and deals day to day
- People who manage a team and need to see its pipeline and reports
- People who handle post-sale accounts and renewals
- People who need read-only access, such as finance or leadership
- One or two administrators who maintain the system
Record ownership
Decide what a record's owner means: who is responsible for the next step, who is credited in reports and who can edit it by default. Then decide how ownership changes: reassignment when a person is absent, rules for shared accounts, and what happens to unowned leads. Unclear ownership produces both duplicated effort and dropped follow-ups. Write the rule in plain words, for example who owns a company and who owns a deal within it, and check that reports will read ownership the same way.
Visibility rules
Visibility is the balance between collaboration and control. Wide visibility helps cover for colleagues and see the whole customer, while tight visibility protects competitive information and reduces noise. Decide this per role and per type of record, and be able to state the reason. A useful test is to name one case where a person needs to see a record they do not own, and one where they should not. If a rule cannot be explained, it will be worked around.
Sensitive fields
Some information deserves narrower access than the rest of the record: negotiated terms, margins, personal details, internal notes about a customer. List these fields, decide which roles need them, and check whether your CRM can restrict them at field level or only at record level. If it cannot, consider whether the data belongs in the CRM at all. We make no privacy-compliance claims on this page; what rules apply to your data is a question for your own advisers.
Admin rights kept few
Administrator access can change everything, including permissions, fields and integrations. Keep the number of administrators small, name them, and give each a backup. Do not let everyday users hold admin rights for convenience. Separate the business owner, who decides what should change, from the administrator, who makes the change, where your team size allows. Keep a record of who has admin rights and review it when people change roles.
Integration users
Systems that connect to the CRM, such as forms, email tools or automations, act as users too. Give each integration its own account with only the access it needs, rather than borrowing a person's login. That way its actions are identifiable in history, it keeps working when a person leaves, and its access can be removed without side effects. Record which integration uses which account and who owns it. See API credentials and service account setup for the general pattern.
Teams and territories
If your team is split by region, product or account size, decide whether those groupings affect visibility, ownership or reporting, and how a record moves between them. Territories that overlap create disputes, so write the tie-breaking rule. Keep the structure as simple as the business allows, because every extra layer is one more thing to maintain when the organisation changes.
Offboarding
When someone leaves, their access should end the same day and their records must not be stranded. Plan in advance who receives their deals and accounts, how open tasks are reassigned and how you keep their history. Also review the integrations and saved views tied to their account. Our guide to CRM handover when a salesperson leaves covers this in more detail, and the web-application view of the same topic is roles and permissions in a web application.
How LATYNEX works on this
LATYNEX is a remote, English-language vendor. We agree one scope and one price in writing, and we document roles as a table before configuring them. For one CRM and one main sales pipeline, the CRM Cleanup & Sales Workflow Setup package (€1,990, fixed scope) fits; multi-team or multi-pipeline permission designs are scoped separately.
Questions
How many roles should a CRM have?+
As few as the work allows. A handful of clear roles is easier to explain, audit and maintain than many fine-grained ones. Add a role only when a real job needs different access.
Should everyone see all records?+
Not necessarily, and not necessarily the opposite. Decide per role and record type, and be able to state the reason. Where transparency helps cover for colleagues, wider visibility is often worth it.
Does every CRM support field-level restrictions?+
No. What you can restrict differs by product and plan, so check before designing around it. If a field cannot be restricted, reconsider whether it should be stored there.
Why give integrations their own accounts?+
So their activity is identifiable, they continue to work when a person leaves and their access can be changed without affecting anyone else.
Who should decide permissions?+
The business owner of the sales process decides what each role needs; the administrator implements it. Write the result down so it can be reviewed.