Permissions decide who sees what, who can edit what, and who can delete the record that just closed. Set them too loose and sensitive revenue data walks out the door with every departure. Set them too tight and reps route around the CRM entirely. This guide walks you through a defensible model: role design, field-level rules, record ownership, sharing exceptions, and the audit cadence that keeps the whole thing honest after year one.
Time: 120 minutes
Before you create a single role in the CRM, pull the org chart and group every seat by what the person actually does with revenue data. Reps need to work their book. Managers need to coach and forecast on their team. Executives need rolled-up visibility across teams. Marketing needs campaign objects and attribution. Finance needs closed revenue and little else. Customer success needs post-sale accounts and tickets. Operations needs admin-level access to configure the system but should not be routinely editing live deals. Write each group on paper with a one-line description of what they do all day. The common failure here is building roles that mirror HR titles instead of CRM behavior. "Director" is not a CRM role. "Manager who sees direct reports plus skip-levels in forecast" is. Resist the temptation to clone one role per title. You want five to eight role shapes for most companies, not twenty. Fewer roles mean fewer edge cases, faster onboarding, and audits you can actually finish in an afternoon.
Every role gets a scope expressed in three dimensions: which objects it can touch, which actions it can take on those objects, and which records inside each object it can see. Objects are the nouns in the system: accounts, contacts, leads, opportunities, products, cases, forecasts. Actions are create, read, edit, delete, share, export, and administer. Record visibility is the hard part. Most CRMs default to one of three patterns: private (only owner and their management chain see it), public read (everyone can see, only owner edits), or public read-write (everyone can edit). Pick private as the default for opportunities, forecasts, and anything with pricing. Pick public read for accounts, contacts, and products so the whole team can look up a customer without filing a request. Reserve public read-write for shared operational data like territories, campaign responses, or ticket queues. Document which object sits in which pattern before you touch the admin console. If you cannot explain the default visibility of each object in one sentence to a new hire, the model is already too complex.
Object-level permissions are the floor, not the ceiling. Most of the risk lives at the field level. A rep who can see an account should probably not see the current ARR, the churn risk score, or the discount floor negotiated with legal. A manager who can see opportunities might not need to see the executive sponsor comments or the custom field marked "internal only." Walk every object and mark each field with one of three states per role: visible and editable, visible but read-only, or hidden entirely. Pricing fields almost always want visible-but-read-only for reps and hidden for everyone outside the deal team. Forecast categories should be editable by managers, read-only for reps, and visible to finance. Health scores and churn probabilities should be hidden from reps who might try to coach the number instead of the customer. Field-level security is tedious to set up and painful to maintain, but it is where most permission failures become breach-worthy incidents. Treat it as a first-class concern, not an afterthought.
Ownership is the second lever after roles. Every account, contact, lead, and opportunity has an owner, and that owner usually drives who can edit the record and who sees it in private-mode objects. Decide how ownership assignment works at creation and how transfer happens when a rep leaves or a territory changes. For new leads, assignment should be deterministic: a routing rule that respects territory, segment, round-robin fairness, and vacation coverage. Manual assignment is the exception, not the default. For account ownership, decide whether a sales rep owns the account for life, loses it after a defined period of inactivity, or hands it off to customer success at close. Each choice has downstream effects on commission plans, forecast ownership, and the conflicts that explode in Q4. Opportunity ownership typically follows the deal: whoever drives the active cycle owns the record, and ownership transfer requires a logged reason and manager approval. Do not let ownership drift. A deal with no owner is invisible; a deal with the wrong owner forecasts wrong.
Default visibility covers eighty percent of the needs. The remaining twenty percent is the long tail of exceptions: a specialist pulled into one deal, a partner rep co-selling with the owner, a leader stepping in for a cross-regional review. Model this with explicit sharing rules and deal teams instead of promoting people to broader roles. A sharing rule says "members of this group get read access to records matching this filter." A deal team says "these named individuals get edit access to this one record." Both are reversible and auditable. Avoid two tempting shortcuts. First, do not grant broad role access just to solve one person's problem; one leak outlives the problem it solved. Second, do not let managers add their reports to deal teams freely; require a logged business reason. Over time the deal-team feature becomes a side channel for undocumented access unless you keep the gate narrow. Review all active sharing rules quarterly, retire any that no longer match live data, and keep the total under thirty for most companies. More than that and the model has become unmanageable.
Every CRM integration ships with a service account, an API key, or an OAuth token. Each of those behaves like a human user with permissions, and each is a common breach vector when it goes unaudited. Create a dedicated service account per integration, never reuse a human admin account to run API traffic, and scope each service account to the smallest permission set that makes the integration work. A marketing automation sync usually needs read on accounts and contacts, write on leads, and nothing else. A finance system typically needs read on closed opportunities and nothing else. A data enrichment tool needs write on specific contact fields and read on account URLs. Document what each service account can touch, store the credentials in a secrets manager that is not the CRM, and rotate tokens on a schedule that matches your human password policy. When an integration is retired, retire its service account the same day. The orphan service account with full write permissions is the single most common pattern behind quiet CRM data corruption.
Permissions drift. A role gets a one-off expansion for a VP who never had it reverted. A field flips from hidden to visible because someone was debugging a report and did not change it back. An integration adds a scope during an upgrade and nobody notices. The only defense is a logged audit of every permission change and a disciplined review of that log. Make sure the CRM is set to log role creation, role modification, field-level security changes, ownership transfers, sharing rule changes, and service-account scope changes. Pipe the log to a system that cannot be edited by CRM admins so the record is tamper-evident. Review the log weekly for the first ninety days after launch, then monthly once the system stabilizes. Each review asks three questions: what changed, who changed it, and does the business reason still apply. Record the answer. The reviewed log is the artifact that passes a SOC 2 audit, satisfies a customer security questionnaire, and tells you honestly whether your model is holding or decaying.
A permissions model that lives in one admin head is a permissions model with a bus number of one. Write it down. A single document should describe every role, every object visibility rule, every field-level override, the ownership and sharing rules, the service-account inventory, and the audit cadence. Store it in version control so changes have a diff. Train every manager on how the model works, how to request changes, and what the review cadence will catch. Schedule a formal recertification once a quarter where every role owner confirms their team still needs the access they have and every sensitive-field policy gets a thumbs-up from the data owner. Recertification sounds bureaucratic until the first time a departing executive takes a full data export with them because nobody noticed their access was never scoped back down. The quarterly cadence is also the right time to retire users who left, reclaim licenses, and check that offboarding actually revoked the access it promised to revoke. Permissions are a product, not a project. Treat them that way.
Most mid-market companies run clean with five to eight roles: rep, manager, executive, marketing, customer success, finance read-only, operations admin, and a limited external partner role. More than ten roles usually signals that field-level overrides and sharing rules are being replaced with role proliferation, which gets expensive to maintain and audit.
Private is the right default for opportunities in almost every B2B motion. The owner and their management chain see the record automatically, and anyone else who needs access gets it through a deal team or an explicit sharing rule. Public read makes forecasting conversations easier but tends to encourage reps to work other peoples deals, which creates compensation disputes nobody enjoys resolving.
Use field-level security whenever two groups should see the same records but different fields. A manager and a rep both work the same deal, but only the manager needs to see the forecast category override. A marketing user and a sales user both see the account, but only sales sees the discount floor. Spinning up a new role for every such difference bloats the model and makes audits miserable.
Trigger a defined offboarding playbook on the last day. Transfer every open opportunity to a named manager, every account to a routing rule that respects the next assigned rep, and every lead to the shared lead queue. Freeze the user account rather than deleting it so historical records keep a valid owner reference. Run a daily report during the transition week to catch records that did not reassign cleanly.
Yes, and arguably more. Service accounts run at machine speed with no human noticing their behavior day to day. Scope every service account to the minimum permissions its integration needs, log every change to that scope, rotate credentials on the same cadence as human passwords, and retire the account the moment its integration retires. The orphan service account with broad write permissions is the single most common breach pattern in CRM data.
Review the audit log weekly for the first ninety days after launch, then shift to monthly once the model stabilizes. Run a formal recertification quarterly where role owners confirm their team still needs the access they have and data owners confirm each sensitive-field policy still matches the business reason. Annual reviews are not enough; drift accumulates in months, not years.
Strkr gives you role shapes, field-level rules, ownership routing, sharing exceptions, and a tamper-evident audit log in one place. Configure once, review on cadence, and leave the spreadsheet governance behind.
No sales call, no migration consultant, no four-month implementation. Enter your card, get 14 days of the full Pro tier, cancel any time before day 14 with zero charge. Spin up a workspace, import your CSV, and have something useful before lunch.
