--- title: Salesforce Permissions Audit Framework type: article created: '2026-04-05' updated: '2026-04-05' source_docs: - raw/2026-03-17-salesforce-meeting-130666556.md tags: - salesforce - permissions - security - crm - best-practices layer: 2 client_source: null industry_context: null transferable: true --- # Salesforce Permissions Audit Framework ## Overview In B2B sales organizations using Salesforce, inconsistent permission sets across the sales team create two distinct failure modes: reps being *blocked from legitimate actions* (e.g., commenting on tasks they created) and reps having *too much access* (e.g., reassigning account or opportunity ownership). A structured permissions audit resolves both by standardizing roles and enforcing explicit ownership controls. This pattern emerged from work with [[clients/quarra/index|Quarra]], where ad-hoc permission assignments had left different sales reps with different access levels, causing both friction and data integrity risk. --- ## The Two Failure Modes ### Under-permissioned: Blocked from legitimate actions A rep who creates a task and assigns it to a colleague may find they cannot comment on or edit that task — because the system treats the *assignee* as the owner and blocks edits from anyone else. This is a common side effect of rules designed to prevent tampering, applied too broadly. **Symptom:** "Insufficient access rights on object ID" errors when a rep tries to interact with a record they created but don't own. ### Over-permissioned: Too much access Reps with elevated permissions (often granted informally to solve a one-off problem) may be able to change account owners, reassign opportunities, or modify records belonging to colleagues. In commission-based or territory-based sales orgs, this creates real risk. **Symptom:** Non-admin users able to change Account Owner or Opportunity Owner fields. --- ## Recommended Permission Structure ### Sales Rep Role (standardized) All reps at the same level should have **identical permission sets**. Differences in access between peers are a maintenance liability and a source of confusion. Reps should be able to: - Create and edit their own Accounts, Contacts, Opportunities, and Tasks - **Comment** on any Task (including tasks assigned to others) - View all Accounts and Opportunities (in organizations where territory visibility is shared) Reps should **not** be able to: - Change the Owner of an Account or Opportunity - Edit or delete comments/notes written by another user - Modify field values on records they don't own (beyond commenting) ### Admin Role Ownership changes — Account Owner, Opportunity Owner — should be restricted to admin-level users only. This prevents accidental or intentional reassignment and keeps the audit trail clean. --- ## Task Object: The Comment vs. Edit Distinction Tasks require particular care because they involve two distinct actors: the **creator** (who defines the work) and the **assignee** (who performs it). A well-designed permission model allows: | Action | Creator | Assignee | Other Reps | Admin | |---|---|---|---|---| | Edit Task details | ✅ | ✅ | ❌ | ✅ | | Add a Comment | ✅ | ✅ | ✅ | ✅ | | Edit another's Comment | ❌ | ❌ | ❌ | ✅ | | Delete another's Comment | ❌ | ❌ | ❌ | ✅ | The key principle: **commenting is collaborative; editing is ownership-gated.** For the comment field itself, a timestamped feed (name + timestamp appended on each entry) is preferable to a single free-text box, which obscures who wrote what and when. See [[knowledge/salesforce/task-object-enhancements|Task Object Enhancements]] for implementation details. --- ## Audit Process 1. **Inventory current permission sets** — document what each named user actually has, not just what their role implies. Ad-hoc grants accumulate over time. 2. **Define the target state** — agree on what the standard sales rep role should and should not be able to do (use the table above as a starting point). 3. **Identify field-level security gaps** — some access issues are not role-level but field-level. Check whether specific fields (e.g., Owner, Close Date, Amount) have independent security rules. 4. **Equalize peers** — all reps at the same level get the same permission set. Remove any individual exceptions. 5. **Restrict ownership changes to admins** — apply this at the object level for both Account and Opportunity. 6. **Test as a non-admin user** — log in as a rep to verify the intended experience before rolling out. --- ## Salesforce Permission Layers (Reference) Salesforce enforces access at multiple levels, which is why a single "permission set" audit may not catch everything: - **Profile / Permission Set** — what objects and actions a user can perform - **Role Hierarchy** — what records a user can *see* based on org structure - **Field-Level Security** — whether a specific field is visible or editable - **Record Ownership Rules** — whether a user can edit a record based on who owns it - **Sharing Rules** — explicit grants to extend visibility beyond the role hierarchy When a rep reports unexpected access errors, check all four layers before concluding it's a permission set issue. --- ## Client Examples - **[[clients/quarra/index|Quarra]] (2026-03-17):** Audit initiated after Tom Proboa was blocked from commenting on a task he created (assigned to Brian Rediman), while Steven Rousseau had excess permissions allowing ownership changes. Action: standardize all sales reps (Proboa, Rousseau, Enzer, Luigi, Fabrizio) to identical permission sets; restrict Account/Opportunity owner changes to admin only. See [[clients/quarra/meetings/2026-03-17-salesforce-optimization-review|meeting notes]]. --- ## Related - [[knowledge/salesforce/task-object-enhancements|Task Object Enhancements]] - [[knowledge/salesforce/lead-vs-account-contact-opportunity-workflow|Lead vs. Account/Contact/Opportunity Workflow]] - [[knowledge/salesforce/new-opportunity-form-best-practices|New Opportunity Form Best Practices]]