Simplified Salesforce Permissions Model: 6 Profiles

Overview

A common failure mode in Salesforce implementations is over-engineering the permissions structure — assigning granular roles to individual job titles until no one can remember what was configured or why. The recommended approach is a two-tier model that keeps things maintainable: broad Profiles define what a user can do, and Roles define what data they can see.

This model was adopted for ^[1] after their existing setup had grown too complex to manage, with too many granular roles mapped to individual positions rather than functional groups.

The Two-Tier Model

Tier	Purpose	Example
Profile	Defines feature access and object-level permissions (create, edit, delete)	Sales profile can create Opportunities but cannot delete records
Role	Defines data visibility within a profile	A Sales Rep role sees only their own Accounts; a Sales Manager role sees all

This separation keeps the permission matrix small and auditable. Field-level security is available but should be reserved for genuinely sensitive data (e.g., internal discount fields) — applying it broadly creates maintenance debt that compounds quickly.

The 6 Standard Profiles

Profile	Approx. Users	Notes
Admin	1	Full access; keep headcount minimal — admins can break things
Sales	~8–9	Standard sales reps + Tom Provo; includes Italian team members
Operations	~11–12	Production and project management staff; includes Nate McCalmont
Executive	~3	Broad read access; may include cross-functional visibility
Finance	~2	Carson + one other; no operational write permissions by default
Marketing	~1–2	Lincoln + one other; requires unique permissions for Account Engagement (Pardot)

Why Marketing is separate: Salesforce's Account Engagement (Pardot) module has its own permission layer. Marketing users need access that doesn't belong in Sales or Ops profiles, making a dedicated profile worthwhile even for a small team.

Key Policy Decision: Remove Delete from Sales and Ops

Sales and Operations profiles should not have delete permission on core objects (Accounts, Contacts, Opportunities). Reasons:

Prevents accidental data loss
Maintains a complete audit trail
Encourages correct behavior: closing a record with a reason rather than erasing it

The alternative to deletion: Users mark records as Closed and select a reason (e.g., Closed - No Fault, Closed - N/A, Closed - Duplicate). If a true deletion is needed, it routes to an Admin. This keeps the pipeline data clean for historical reporting.

Implementation Notes

Italian team members should be assigned to the same Sales or Operations profiles as their US counterparts. Location can be tracked via a field on the User record, not via a separate profile.
Nate McCalmont is currently assigned to Operations. If a Projects object is built out later, his role may be elevated to a quasi-admin scope for that object specifically — but profile assignment stays at Operations for now.
Tom Provo was missing from the active user list at time of audit and needs to be added to the Sales profile.
The existing role structure had too many entries mapped to individual job titles (e.g., "Assistant Plant Manager"). These should be consolidated into functional roles (e.g., "Operations - Production") that map cleanly to the 6 profiles above.

What to Avoid

Field-level security everywhere: Tempting for control, but creates a maze. Reserve it for genuinely confidential fields.
Roles as job titles: Roles should describe data scope (e.g., "Sales - Rep" vs. "Sales - Manager"), not org chart positions.
Too many admins: Every additional admin is a liability. One internal admin (Lincoln) plus the implementation team is sufficient.

^[2]
^[3]
^[4]