---
title: 'Simplified Salesforce Permissions Model: 6 Profiles'
type: article
created: '2026-04-05'
updated: '2026-04-05'
source_docs:
- raw/2026-03-20-impromptu-zoom-meeting-131611577.md
tags:
- salesforce
- permissions
- crm
- best-practices
layer: 2
client_source: null
industry_context: null
transferable: true
---

# 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 [[clients/quora-stone/index|Quora Stone]] 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.

---

## Related

- [[clients/quora-stone/index|Quora Stone Client Overview]]
- [[knowledge/salesforce/proposal-workflow-two-phase|Proposal Workflow: Two-Phase Automation Plan]]
- [[knowledge/salesforce/opportunity-stages|Opportunity Stage Optimization]]