How to set up CRM permissions and roles

Permissions start with roles, not with checkboxes. Before you open the admin console, draw the role matrix on one page: admin at the top, then manager, rep, finance, and CS as the core five, plus any custom roles your business needs. For each row, write a one-sentence job description and the single most sensitive thing that role must be able to do. Admins own the whole tenant and configuration. Managers coach a team and see team pipeline. Reps work their own book. Finance sees invoice-grade revenue data across all accounts. CS owns post-sale health and renewal signals. The matrix is the artifact every subsequent decision references, so stakeholders stop arguing about edge cases and start arguing about which row an edge case belongs in.

• List the five core roles and the custom roles your business needs: BDR, sales engineer, partner manager, legal reviewer
• Write a one-sentence job description per role so the scope is unambiguous when a hiring manager picks the role for a new hire
• For each role, name the one most sensitive capability it must have, so you know what to test when the role gets a new permission
• Get sales, marketing, finance, and support leaders to sign the matrix before any permission is granted in the tenant

Once roles exist, decide what records each role can see. The three standard scopes are view-all, view-team, and view-own, and most roles map cleanly to one. Admins and finance usually get view-all because their job depends on cross-book visibility. Managers get view-team scoped to the people in their reporting line, which is why the manager hierarchy on the user record has to be clean before this step. Reps get view-own, meaning their own accounts, their own opportunities, their own tasks. CS typically gets view-team for the customers in their book plus view-all on open support tickets. Write the scope decision next to each role on the matrix and get leadership to sign it a second time, because scope is where politics shows up and the written sign-off is the only defense against post-launch rework.

• Pick a scope for each role: view-all, view-team, or view-own, and write the choice next to the role on the matrix
• Confirm the manager hierarchy on the user table is clean so view-team actually resolves to the right people under each manager
• Decide the cross-object rule: a rep who owns the account also sees its contacts, opportunities, and tasks by inheritance
• Write the exception policy: when a rep legitimately needs another rep's record, do they request access or does a manager share it manually

The core five roles cover 80% of the org, and then you have the exceptions. BDRs need view-own on leads but typically no visibility into closed-won revenue. Sales engineers need read-only on all opportunities so they can jump into deals without pulling the AE every time. Partner managers need read on their partner-sourced opportunities and write on partner records but nothing else. Legal reviewers need read on contracts but no edit on anything commercial. Build each custom role as a narrow delta against the closest core role: a BDR is a rep minus closed-won read, a sales engineer is a rep plus read-across. Keep the custom role count under 10 if you can, because every additional role is another row in the permission audit matrix and another thing a new admin has to understand.

• Pick the closest core role as the base and write the custom role as a delta: plus these three capabilities, minus these two
• Document the business reason for every custom role next to its definition so the next admin knows why it exists
• Set a cap on custom role count (eight is a reasonable ceiling for most teams) and defend it against role sprawl
• Review custom roles every quarter and merge or retire the ones with fewer than three users assigned

Record-level scope decides who sees the record. Field-level permissions decide who sees which columns on it. This matters because an account record is not a single trust boundary: the name and website might be fine for the whole company, but the annual revenue, the renewal date, the signed contract value, and the primary contact phone number are not. Walk every CRM object and classify each field into one of the four data tiers from your security policy. Public and internal fields stay on the role defaults. Confidential and restricted fields get an explicit allow-list of roles that can read them, with write restricted even more tightly. Finance and admin usually read restricted fields. Managers read most confidential fields on their team. Reps read confidential fields only on their own records. Document the classification on a per-field basis and ship it as a one-page data dictionary alongside the permission matrix.

• Walk every object (account, contact, lead, opportunity, contract, invoice, note, task) and classify each field into one of four tiers
• Lock restricted fields (bank data, personal contact numbers, contract values, revenue) to finance and admin by default
• Set confidential fields (renewal date, forecast category, deal notes) to the owning rep and their manager plus admin and finance
• Publish the field classification as a one-page data dictionary so new admins know the rule before they add a new field

A permission model you cannot audit is a permission model you cannot trust. Turn on the audit log at the tenant level for every permission grant, every role assignment, every sensitive-field read, and every bulk export. Set alerts on three high-signal events: a user gaining admin, a bulk export from any role that is not admin or finance, and any read of a restricted field by a role that was not on the allow-list. Route the alerts to a named security owner, not a shared alias. Then schedule a 60-minute quarterly review where the security owner walks the matrix with sales and RevOps leadership: who was added to which role, which custom roles are still earning their place, which fields were newly classified, and which alerts fired and what the resolution was. Audit without a review is theatre.

• Turn on the tenant audit log for role grants, record access, field reads on restricted data, and bulk exports
• Alert on three events: admin grant, non-admin bulk export, restricted-field read by an off-list role
• Route alerts to a named security owner on a dedicated Slack channel, never a shared inbox or an unmonitored alias
• Schedule a 60-minute quarterly permission review on the calendar and treat it like a QBR, not an optional meeting

Living permission models drift because the people who built them leave or forget, and the next admin reinvents the wheel from scratch. Capture the whole model in a single internal doc: the role matrix, the scope decisions, the custom-role deltas, the field classification data dictionary, the audit alert list, and the quarterly review calendar. Store it in the admin wiki and link to it from the CRM admin console. When a hiring manager asks what role a new BDR should get, they open the doc. When security asks why finance can read contract value, the doc answers. When a VP challenges a scope decision, the doc shows the sign-off date and the leader who signed. Documentation is the difference between a permission model and a permission folklore.

• Create a single admin-wiki page per tenant with role matrix, scopes, custom roles, field classification, and audit alerts
• Link to the doc from the CRM admin console header so new admins find it before they start granting access
• Version the doc with change notes so you can see what changed between quarterly reviews and who approved each change
• Review and update the doc at every quarterly permission review, not as a cleanup pass after someone complains

A permission model only protects data if the humans understand it. Add a 20-minute module to new-hire onboarding that walks every joiner through their role, their scope, the restricted fields they cannot see, the escalation path for legitimate exceptions, and the audit log that captures every sensitive action. Reps need to know that view-own is intentional, not a bug. Managers need to know that view-team ends at their reporting line. Finance needs to know which fields are tier-four restricted and why. The training is not security theatre; it is the primary channel by which the model becomes a shared norm instead of a surprise. Record it once, update it every quarter, and make completion a prerequisite before the user is activated in the tenant.

• Build a 20-minute recorded module covering roles, scopes, restricted fields, escalation path, and audit visibility
• Make completion a prerequisite for CRM activation so no one gets a login before they know the rules
• Refresh the recording every quarter so it reflects the current role matrix, not last year's version
• Add a 5-question quiz at the end so completion is attestable in an audit, not just a checkbox on an HR form

Promotions, lateral moves, team splits, mergers, and departures all break the permission model if nobody resets access at the moment of the change. Build a lightweight workflow: HR triggers a notification to the CRM admin on every role change, the admin opens the user record, confirms the new role matches the new job, and revokes any legacy permissions that no longer apply. Departures get the harder workflow: deactivate the user, transfer ownership of their records to the manager, and run a 30-day watch for inbound touches on their old email so no in-flight deal gets dropped. Role changes are the single highest-risk moment in the permission model because the person retains access they no longer need, which is how most access-sprawl incidents start.

• Wire HR role-change events to a CRM admin notification so no promotion or transfer slips through without a permission review
• On every role change, confirm the new role is correct and revoke any legacy permissions the user carried over from the old role
• On every departure, deactivate the user, transfer record ownership to the manager, and watch inbound touches on the old email for 30 days
• Log every role-change permission review in the audit trail so the next quarterly review can confirm it happened