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.
| 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.
| 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.
Sales and Operations profiles should not have delete permission on core objects (Accounts, Contacts, Opportunities). Reasons:
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.