CRM Permissions: How to Set Roles and Field Access for a Sales Team

CRM permissions are the settings that decide which menus, records and fields each user sees, set by role (rep, manager, finance, admin), then narrowed by record ownership (which deals or accounts someone can open) and field-level security (which fields they can read or edit). Most teams get the role part right and stop; field-level access is where sensitive numbers leak.

This guide gives you a worksheet for designing roles around four common sales-org jobs, a worked example of keeping cost data private, and a quarterly review that catches access nobody remembers granting. For how permissions fit into the rest of a CRM’s structure, see how a CRM organizes records, which covers the access model at a higher level; this post is the hands-on companion for actually building the roles.

What are CRM permissions, exactly?

“CRM permissions” is shorthand for several controls that stack on top of each other. Getting them confused is the most common cause of either overexposed data or a rep who can’t do their job.

• Role or profile: what a user can do in general: which modules appear, whether they can export, delete, or change settings. This is the coarse-grained switch.
• Department or team: which slice of the organization a user belongs to, often used alongside role to decide default visibility (a department typically sees its own records, not another team’s).
• Record ownership and sharing: which specific records (this deal, that account) a given user can open. Ownership is usually the default (you see what you own or what’s shared with you); managers typically see everything their team owns.
• Field-level security: within a record a user can already open, which individual fields are visible or editable. This is the layer that hides a cost field from a rep who can otherwise see the whole deal.

The formal name for the role layer is role-based access control, or RBAC: a model where permissions are assigned to roles rather than to individual people, so a new hire inherits the right access the moment they’re assigned a role instead of someone rebuilding it by hand. NIST’s definition describes it the same way: access is tied to the role, not the person, which is what makes RBAC easy to audit and easy to reassign when someone changes jobs.

Who should see what in a CRM?

Before opening a permissions screen, write down what each job actually needs to see and do. The table below is a starting worksheet for a typical B2B sales org: copy it, then adjust the “sees” column to match your own team’s structure.

Two columns matter more than the others when you’re just starting: “records it sees” catches the ownership question, and “fields it should NOT see” catches the field-level question most teams skip until a rep sees a number they shouldn’t have.

How do you design roles for a sales team?

Treat this as a five-step project with a named owner at each step, not a settings screen you fill in from memory.

1. List the objects that matter. Leads, contacts, accounts, deals, quotes, activities, reports. Owner: sales ops or the admin. Output: one list, shared with sales leadership for a sanity check.
2. List the jobs, not the people. Use the worksheet above as a start (rep, manager, finance, admin) and add any job unique to your org (a solutions engineer who needs read-only deal access, for example). Owner: sales manager, with HR/org-chart input if roles map loosely to titles.
3. Set record-level access first. Decide, per job, whether they see only their own records, their department’s, or everything. This is usually role plus department together, not role alone. Owner: admin, reviewed by sales manager.
4. Set field-level access second, only where it matters. Don’t lock every field: lock the handful that are genuinely sensitive (cost, margin, commission, or anything a competitor would want). Owner: admin, with finance sign-off on cost fields specifically.
5. Test with one real user per role before rolling out. Log in as (or shadow) one rep, one manager, before turning the new roles on for everyone. Owner: admin. Output: a short list of “can’t do X” gaps to fix before go-live, not after.

Worked example: keeping margin and buy price private

Example: a hypothetical 14-person industrial distributor in Boise, Idaho, sells through eight reps, two sales managers and one finance lead who also runs revenue operations part-time. Every deal record carries a sell price the customer sees and a buy price plus margin that the company does not want visible to a rep who might, intentionally or not, mention it to a customer or a competitor during a long sales cycle.

The distributor’s role design puts sell price, quantity, and customer terms on every rep’s view of the deal: the fields a rep needs to run the sale. Buy price and the calculated margin sit on the same record but are set to field-level “no access” for the rep role and “read” for sales manager and finance. A rep opens the deal, quotes it, and moves it through the pipeline without ever seeing the two hidden fields; a manager reviewing the same deal for a discount approval sees the margin and can make an informed call.

Nothing about the deal record changes for the rep except those two fields: they still own the deal, edit everything else, and log every call and email against it. That’s the point of field-level security over a blunter control: it narrows exactly the sensitive number, not the rep’s ability to do their job.

What is the difference between record-level and field-level access?

Record-level access answers “can this person open this specific record at all.” Field-level security answers a narrower question: “of the fields on a record this person can already open, which ones can they read or edit.” Confusing the two leads to two opposite mistakes: restricting a whole record when only one field was ever the problem, or assuming a hidden field is protected when the real issue is that the wrong person can open the record in the first place.

The principle of least privilege, as NIST’s glossary defines it, is the general rule both layers serve: give each person the minimum access their job requires, and add more only when the job changes, not before. Record-level and field-level controls are the two places in a CRM where that principle actually gets applied.

How do you run a quarterly CRM access review?

Access that was correct on day one drifts: someone changes teams, a contractor’s project ends, a role gets a permission bolted on to solve a one-off problem and it’s never removed. A fixed quarterly review catches the drift before it becomes a habit.

• Pull the full user-role list. Every active user and the role, department and any individually granted permission attached to them.
• Flag anyone who changed jobs or left. Cross-check against HR’s current roster; a former employee’s account should already be deactivated, but this catches the ones that slipped through.
• Check for roles wider than the job. Look for a rep with manager-level record access, or a one-off field permission granted to solve a single ticket six months ago and never revisited.
• Confirm the sensitive fields are still locked down. Spot-check margin, cost and commission fields against the current role list: the fastest way a leak happens is a new role inheriting the wrong field permissions when it’s cloned from an existing one.
• Log the review. Who ran it, what changed, when the next one is due. This log is what a security questionnaire or a new sales manager asks for first.

Owner: whoever administers the CRM, with a sales manager and finance sign-off on the sensitive-field spot check. Output: a short list of changes made, filed somewhere it can be found six months later.

What mistakes weaken CRM permissions?

• Cloning a broad role to save time. A new “junior rep” role built by copying “sales manager” and removing a couple of checkboxes usually keeps access nobody meant to grant.
• Locking a whole record instead of one field. A rep who can’t open a deal at all can’t work it: the fix for one sensitive number is a field permission, not a record restriction.
• No review cadence. Permissions set correctly at launch and never revisited drift for years; nobody notices until an audit or a departure forces the question.
• Treating role and department as one thing. A role sets what a job can do; a department usually sets which records it can see by default. Skipping the department layer means every rep sees every other rep’s pipeline.
• No test user before rollout. The first person to discover a role is missing something it needs is a live rep on a live deal, not an admin in a test environment.

How does Senitix CRM handle permissions?

Senitix CRM sets access by role, department, record ownership and field, on every plan, so the worksheet above maps directly onto real settings rather than a workaround. Field permissions keep sensitive values, like margin or buy price, visible only to the roles that need them, exactly as in the worked example above.

An access explorer shows why a specific person can or can’t see a specific record, which turns the quarterly review from guesswork into a lookup. A change history is kept on each record, and a Setup Audit Trail records admin-level changes: who edited a role, a field permission, or a layout, and when. Sharing beyond ownership is set by hand, record by record.

See the full list under security and access controls on the features page, or read how Senitix approaches data protection more broadly on the GDPR and data protection page. For the checklist to run before you roll any of this out, see the CRM security checklist. Plan details are on the pricing page, or talk to sales about a role design for a larger org.

Frequently asked questions

What is the difference between a CRM role and a permission?

A role is a named bundle of permissions (“sales rep,” “sales manager”) assigned to a user so they don’t need each setting configured individually. A permission is the individual setting itself: can view, can edit, can delete, on a specific object or field. Roles make permissions manageable at scale; without them, an admin would set every permission for every user one at a time.

Should every sales rep have the same permissions?

Usually yes, within a role: reps doing the same job should have the same access, which is the point of role-based design. Exceptions (a senior rep who also mentors and needs visibility into a colleague’s deals) are better handled with a specific sharing exception than a whole new role, unless enough people need the same exception to justify one.

Who should be able to change permissions in a CRM?

As few people as the org can manage with, typically one admin, plus a backup so access changes don’t stall when that person is out. Sales managers can usually request changes but shouldn’t have standing access to the permissions screen itself; that keeps a single, auditable point of change.

How do you know if your CRM permissions are too loose?

The clearest sign is a rep who can see or edit something they’ve never once needed for their job: another team’s pipeline, a cost field, a setup screen. If a quarterly review turns up more than a couple of these, the roles were likely cloned from something broader than the job actually required.