View All and Modify All are object-level permissions that bypass the Salesforce sharing model — Organization-Wide Defaults, role hierarchy, sharing rules, and manual shares are all ignored. A user with View All on an object can read every record of that object regardless of who owns it. With Modify All, they can also edit, delete, and transfer those records. These are the strongest record-access permissions short of the org-wide “View All Data” and “Modify All Data” system permissions.
How they fit into the security model
Most of the Salesforce sharing model is built around granting access from a restrictive baseline (OWD). View All and Modify All sit outside that model — they grant unconditional access at the object level. Salesforce typically uses them for:
- Data migration users who need to load or export entire datasets
- Integration users that synchronize records bidirectionally with external systems
- Compliance / audit users who must inspect all activity on an object
- Support staff who need to find any record by global search regardless of ownership
Object-level vs system-wide
There are four related permissions interviewers love to compare:
| Permission | Scope | Where it lives |
|---|---|---|
| View All (per object) | All records of that one object | Object Permissions section of profile/perm set |
| Modify All (per object) | All records of that one object — read + edit + delete + transfer | Object Permissions section of profile/perm set |
| View All Data | Every record of every object in the org | System Permissions section — typically only sysadmins |
| Modify All Data | Every record of every object in the org — full CRUD | System Permissions section — typically only sysadmins |
The per-object variants give surgical access without granting org-wide power. A data steward might have View All on Account to do deduplication, without needing to see Opportunity financials.
What they actually bypass
A user with View All on Opportunity can see:
- Opportunities owned by other users — bypassing Private OWD.
- Opportunities owned by users not below them in the role hierarchy — bypassing the hierarchy.
- Opportunities not covered by any sharing rule.
- Opportunities not explicitly manually shared with them.
What View All does not bypass:
- Field-level security — they still can’t see fields where FLS is hidden for their profile/perm set.
- CRUD — wait, actually, View All implies Read at minimum (and Modify All implies Read/Create/Edit/Delete). Salesforce won’t let you assign View All without the prerequisite Read.
- Login restrictions — IP ranges, login hours, MFA still apply.
Real scenario
“The data team needs to export every Lead in the org for a deduplication exercise, but they shouldn’t be sysadmins.”
Don’t grant View All Data (system permission) — that exposes every object including HR custom objects and confidential opportunities. Instead, create a permission set called “Lead Data Steward” that grants View All on the Lead object specifically. The data team can now query and export every Lead via Data Loader or Workbench, while their visibility on Opportunity, Case, etc. follows the normal sharing rules.
When to use Modify All vs View All
Modify All is strictly more powerful than View All — it implies View All plus edit, delete, and transfer. Choose carefully:
- View All for read-only roles: auditors, dedupe analysts, reporting users.
- Modify All when the user genuinely needs to update or reassign records they don’t own — typically data stewards or integration users.
If you only need visibility and not edit power, View All is the right answer. Granting Modify All “just in case” violates least-privilege.
Caveats Salesforce tests on
- View All on a master-detail child is governed by the parent’s access. View All on the parent gives access to children too.
- View All is not available on every object — a small number of system-managed objects don’t expose it.
- View All and Modify All on the User object do exist but should almost never be granted; they let the user see and edit other users’ settings, profiles, and password resets.
Verified against: Salesforce Help — “View All” and “Modify All” Permissions Overview. Last reviewed 2026-05-17.