"View All / Modify All" in Salesforce — the bypass to watch
View All and Modify All quietly bypass the Salesforce sharing model. What they do, where they come from, who to check, and why they matter for AI agents.
Most of the Salesforce sharing model is about carefully granting record access. View All and Modify All throw that out the window — they let a user see or change everything, ignoring sharing entirely. They’re essential for admins and dangerous when they spread. Here’s what they do and how to keep them in check.
What they actually do
These permissions bypass the sharing model — org-wide defaults, role hierarchy, sharing rules, the lot:
- View All — see every record of an object.
- Modify All — see, edit, delete and transfer every record of an object.
A user with View All on Cases sees every case in the org, even with a Private org-wide default and no sharing rule in sight. Sharing simply doesn’t apply to them for that object.
When these are present, the rest of the sharing model is irrelevant — they sit above it.
Two scopes: object vs system-wide
| Permission | Scope | Effect |
|---|---|---|
| View All (object) | One object | See all records of that object |
| Modify All (object) | One object | Full control of all records of that object |
| View All Data | Whole org | See (almost) all records, all objects |
| Modify All Data | Whole org | Full control of (almost) all records, all objects |
The object-level versions are scoped and sometimes legitimate. The system-wide View All Data / Modify All Data are the heavy artillery — powerful, and the ones to guard most closely.
Where they come from
- System Administrator profile — ships with View All Data and Modify All Data by default.
- Custom profiles and permission sets — frequently granted to solve a one-off (“just let support see all cases”) and then forgotten.
Because a user’s permissions are the union of their profile and every assigned permission set, these can hide in any one of several permission sets — which is what makes them easy to lose track of. They’re closely tied to profiles and permission sets.
Why they’re the first thing to check when access looks wrong
When a user can see a record they shouldn’t, the Sharing button may show nothing — because the access isn’t coming from sharing at all. View All / Modify All grant access without appearing as a share. So before you dig through sharing rules, rule these out.
Why they matter doubly for AI agents
An AI agent inherits its running user’s permissions. If that identity carries View All Data, the agent can read every record in the org on request — bypassing every sharing rule you configured. Confirming the agent’s identity is free of these permissions is a core step in auditing access before deployment.
Keeping them under control
- Inventory every profile and permission set for object-level View All/Modify All and system-wide View All Data/Modify All Data.
- List the users who hold each, directly or via permission sets.
- Apply least privilege — replace blanket View All with scoped sharing rules wherever the access doesn’t truly need to be org-wide.
- Re-check after changes — a new permission set can reintroduce a bypass silently.
Surfacing the bypass automatically
The hard part is that these permissions don’t show up where you look for sharing — they’re a separate switch, in any of many permission sets, that silently overrides everything else. AgentForceAccess factors them in automatically: when it explains why a user (or an agent’s user) can see a record, “they have View All Data — sharing doesn’t apply” is surfaced as plainly as any sharing rule, so the bypass stops being the thing you miss.
Frequently asked questions
What exactly do View All and Modify All do?
They grant access to every record of an object, ignoring the sharing model. View All means see every record; Modify All means see, edit, delete and transfer every record. Object-level versions apply to one object; the system-wide "View All Data" and "Modify All Data" apply to (almost) all objects at once.
Who has these permissions by default?
The System Administrator profile includes View All Data and Modify All Data. Beyond that, they appear on custom profiles and permission sets — often added to solve a one-off access need and never removed. Audit every profile and permission set, not just admins.
Why are these dangerous for AI agents?
An agent inherits its running user's permissions. If that user has View All Data, the agent can read every record in the org on request, bypassing all the sharing you carefully configured. Before deploying an agent, confirm its identity does not carry these permissions.
How do I find who has View All / Modify All?
Check each profile and permission set for object-level View All/Modify All and the system-wide View All Data/Modify All Data, then list their assigned users. This is tedious manually because the permission can come from any of several permission sets a user holds.
See it on your own org
AgentForceAccess explains, in plain English, why any user can see any record or file — across every Salesforce sharing mechanism.
Request early access