In the Salesforce security architecture, object-level permissions sit directly at the top of the data access pyramid. Understanding how permissions like View All and Modify All bypass standard record-level sharing models is essential for passing CTA scenarios and maintaining enterprise data governance.
Core Security Concepts
Two major object-level permissions sit above the record-level sharing architecture:
- 'View All' (Object): Grants read access to every record of an object, overriding OWD settings and active sharing rules.
- 'Modify All' (Object): Grants read, write, transfer, and delete permissions across every record of an object.
- System Super-Permissions: Org-wide 'View All Data' and 'Modify All Data' grant global access across every object and should be restricted to System Administrators.
- Overriding Mechanics: An OWD set to Private has no effect on a user holding View All for that target object.
- Restriction Rules Exception: Restriction Rules are the only security mechanism capable of scoping down access for a user holding object-level View All.
Permission Matrix Comparison
| Permission | Scope | Overrides Sharing? | Target Assignment |
|---|---|---|---|
| View All (Object) | Single Object | Yes (Read) | Support leads, global reporting roles |
| Modify All (Object) | Single Object | Yes (Read / Write / Delete) | Data admins, integration users |
| View All Data | All Org Objects | Yes (Read) | System Administrators only |
| Modify All Data | All Org Objects | Yes (Read / Write / Delete) | System Administrators only |
• Rule: These object permissions override record-level sharing. Grant the narrowest scope possible.
• Gain: Solves global visibility requirements without generating complex sharing recalculations or maintenance.
• Price: Completely disables OWD and sharing rules for that user on the target object.
• Performance Impact: View All costs zero calculation overhead. The platform bypasses sharing table joins completely.
Architect Scenario Q&A
Q: OWD on Case is Private, but a user's profile has 'View All' and 'Modify All' on Case. What can they actually do?
🎯 Say this first: They can view, edit, transfer, and delete every Case in the org because object permissions override record-level sharing completely.
Detailed Explanation: The Private OWD setting is bypassed. View All and Modify All operate at the object layer, making OWD, role hierarchy, and criteria-based sharing rules irrelevant. The only feature that can restrict this user is a Restriction Rule.
Q1: A user can see records they shouldn't, but the sharing audit shows no sharing rules grant access. Where do you check?
Answer: Audit the following five areas in order:
- Object permissions on their profile and assigned Permission Sets for View All or Modify All.
- System permissions for global View All Data or Modify All Data.
- Implicit sharing rules inherited from parent object relationships.
- Role Hierarchy position granting visibility over subordinates.
- Public Group or Team memberships.
Q2: A support lead needs to see all Cases but NOT all Contacts in a Private OWD org. How should you design this?
Answer: Grant View All on Case via a dedicated Permission Set. This satisfies the requirement for global Case access while preserving Contact privacy. Alternatively, if "all cases" really means "all cases in their region," use a criteria-based sharing rule instead of View All to keep access bounded and regionalized.
Conclusion
View All and Modify All provide high-performance blanket access for administrative or global reporting needs. However, because they bypass the standard sharing recalculation model, they must be governed tightly via Permission Sets to avoid unintended data exposure.