View All, Modify All and the All Data Permissions

Module 1 of 6 in the chapter Overrides and Implicit Sharing: What You Get for Free, chapter 10 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: Who can see every record, whatever the sharing says, and how do you find every one of them?

Everything in chapters 6 to 9 writes access into the file cabinets: the owner, the hierarchy, rules, teams, territories. This chapter is about the access you get without building any of that. It starts with the permissions that skip the cabinets altogether.

As soon as you check View All, you bypass the share table. As soon as you check Modify All, you bypass the share table and get edit. A user with View All on an object sees every record of it, top to bottom, and there’s no way to hide a record from them. Chapter 5, module 5 put this on the map as way 13. This module takes it apart.

Four permissions, two sizes

Salesforce’s words: “The ‘View All’ and ‘Modify All’ permissions ignore sharing rules and settings, allowing administrators to grant access to records associated with a given object across the organization” (“View All” and “Modify All” Permissions Overview (opens in a new tab), Salesforce Help, checked 2026-11-07).

They come in two sizes:

• On one object: View All Records and Modify All Records. Object permissions, on a profile or a permission set. Salesforce says they’re for “Users who manage records for specific objects” (same page).
• On every object: View All Data and Modify All Data. User permissions, for “Managing all data in an organization; for example, data cleansing, deduplication, mass deletion, mass transferring, and managing record approvals.” Users with them “can view (or modify) all apps and data, even if the apps and data aren’t shared with them,” and they’re meant for “Administrators of an entire organization who require widespread access” (same page).

And Salesforce’s advice on choosing between them: “‘View All Records’ and ‘Modify All Records’ can be better alternatives to the ‘View All Data’ and ‘Modify All Data’ permissions” (same page). If someone needs every record of one object, give them that one object, not the whole org.

What’s a good reason? Salesforce gives one. Opportunities are Private, but “the whole Sales Operations team, which has members in multiple different roles, must see all opportunities.” So you create a permission set with View All Records on opportunities and assign it to them (View Sharing Overrides (opens in a new tab), Salesforce Help, checked 2026-11-07). Notice the shape of that reason: a team that cuts across the hierarchy, and a job that really needs every record of that one object. Not “a user couldn’t see some records today.” Chapter 1, module 3 tells that story and its side effects.

Click to enlarge

What they don’t open

Powerful as they are, they have edges, and an architect needs to know every one.

• Fields. “View All Data, Modify All Data, and View All Records or Modify All Records for a given object don’t override field-level security” (Permissions Overview). The user still needs field permissions, or View All Fields on that object. Chapter 4, module 1 covers View All Fields.
• External users. These permissions, and View All Fields, “can’t be assigned to external users” (same page). A site user never skips the cabinets this way. Part 3 covers what they get instead.
• Some objects. View All Records and Modify All Records “aren’t available for ideas, price books, article types, and products” (same page).
• The standard children of a parent. Here’s the one that surprises people. “View All Records for a given object doesn’t automatically give access to its standard detail objects and vice versa.” View All on accounts doesn’t open the account’s contacts, opportunities or cases; those still need Read through sharing. “However, View All Records for a given object does give access to its child custom object records without access being granted via sharing” (same page). A custom child in a master-detail relationship follows its parent. Module 2 picks up exactly this: what the platform shares between parents and children by itself.

And one thing they do open that you might not expect. On a detail object in a master-detail relationship, View All Records or Modify All Records needs View All Records on the parent, and Setup turns it on for you when you save (chapter 6, module 6). A restriction rule doesn’t stop them either (chapter 6, module 5).

Their neighbors

A few other permissions sit next to these four. They aren’t way 13, but they’re on the same page, and an architect reviewing an org should know them.

• View All Users grants “Read access to all users.” Anyone with Manage Users gets it automatically (Permissions Overview). Chapter 6, module 7 covers user records.
• View All Lookup Record Names lets someone see record names in “all lookup and system fields,” such as Owner, Created By and Last Modified By. It “only applies to lookup record names in list views and record detail pages” (same page). The name, not the record.
• Query All Files needs View All Records (same page). Chapter 12 covers files.
• Modify Metadata Through Metadata API Functions. If someone only deploys, this gives them “the access they need for deployments without providing access to org data” (same page). Don’t give a deployment user Modify All Data to make a pipeline work.

No row, so where do you look?

Here’s the problem with overrides. They write no row in any share table. Query AccountShare and you’ll never find the people with View All on accounts. You find them in their profiles and permission sets.

Salesforce gives you one place in Setup. In Sharing Settings, select an object from the Manage Sharing Settings For list, and the page “includes a Sharing Overrides related list, which shows any profiles that ignore sharing settings for that object.” For each profile, it shows which of the four permissions it holds (View Sharing Overrides).

Read the note on that page carefully: “The Sharing Overrides list doesn’t show permissions granted through permission sets, which may also override sharing settings for an object” (same page). And today most access is given with permission sets (chapter 3). So the Setup list shows you the profiles, and misses most of what you’re looking for.

To see everything, query it. Object permissions live in the ObjectPermissions object, with a field for each permission, including PermissionsViewAllRecords and PermissionsModifyAllRecords (ObjectPermissions (opens in a new tab), Object Reference, Winter ‘27, checked 2026-11-07). Every profile has a permission set of its own behind it, flagged IsOwnedByProfile, and “you can query their values on permission sets owned by a profile” (PermissionSet (opens in a new tab), Object Reference, Winter ‘27, checked 2026-11-07). So one query covers profiles and permission sets together:

SELECT Parent.Label, Parent.IsOwnedByProfile,
       PermissionsViewAllRecords, PermissionsModifyAllRecords
FROM ObjectPermissions
WHERE SobjectType = 'Opportunity'
  AND (PermissionsViewAllRecords = true OR PermissionsModifyAllRecords = true)

And for the two that cover every object, ask the permission sets themselves:

Each user permission is its own field on PermissionSet, named for the permission: Salesforce’s reference calls them Permissions<PermissionName>, and its own example asks for PermissionsModifyAllData (PermissionSet (opens in a new tab), Object Reference for the Salesforce Platform, checked 2026-11-07). The number of these fields varies with your org and its licenses, so describe PermissionSet in your org before you rely on a name.

SELECT Label, IsOwnedByProfile
FROM PermissionSet
WHERE PermissionsViewAllData = true OR PermissionsModifyAllData = true

You need View Setup and Configuration to query ObjectPermissions (ObjectPermissions). Then go from the permission sets to the people: who’s assigned each one, directly or through a permission set group. And remember that a permission set group can mute a permission (chapter 3, module 3), so a permission set on the list isn’t always a person with the access. Check the user, not only the set.

Click to enlarge

Don’t test as the admin

One more reason to know who holds these. In class, while demonstrating an owner change, I took a record back and said it out loud: I’m a system admin with View All and Modify All, I can see everything. That’s fine for setting up a demo. It’s useless for testing one.

If the person testing your sharing has View All Data, every test passes. Test as the users who’ll actually live in the model, without the overrides. Chapter 13 covers testing with three users.

Restrict them

My position hasn’t changed: really watch the use of View All and Modify All. Restrict them to your system admins and the few people with a written reason, like Salesforce’s Sales Operations team. Don’t make them a common tool in your toolbox. Every one you grant is a door that no sharing rule, hierarchy or restriction rule can close.

What an architect decides here

• Who holds View All Records and Modify All Records on each object, each with a written reason.
• Who holds View All Data and Modify All Data: the org’s administrators, and nobody as a shortcut.
• Where one object’s View All Records can replace View All Data.
• That deployment and integration users get the narrower permissions they need, such as Modify Metadata Through Metadata API Functions, not Modify All Data.
• How the overrides are reviewed: the Sharing Overrides list for profiles, plus a query for permission sets, on a schedule.
• That nobody tests the sharing model as a user with an override.

Beyond the exam: what AI changes. An agent’s user with View All on an object sees every record of it, in every answer it gives, and there’s no row in any share table to show it. So run the override query for your agent users first, and keep the answer at zero. If an agent can’t find what it needs, fix its sharing, not its permissions. And when an AI assistant reviews your org’s security for you, ask it to check permission sets, not only the Sharing Overrides list. Chapter 20 covers agents.

Explore

• “View All” and “Modify All” Permissions Overview (opens in a new tab), Salesforce Help (checked 2026-11-07)
• View Sharing Overrides (opens in a new tab), Salesforce Help (checked 2026-11-07)
• ObjectPermissions (opens in a new tab), Object Reference, Winter ‘27 (checked 2026-11-07)
• PermissionSet (opens in a new tab), Object Reference, Winter ‘27 (checked 2026-11-07)