---
title: "View All, Modify All, View All Data, Modify All Data"
url: "https://trailassembly.com/view-all-modify-all-explained/"
topic: "Admin and Permissions"
published: "2026-09-13T07:08:29+00:00"
updated: "2026-10-06T13:54:14+00:00"
---

# View All, Modify All, View All Data, Modify All Data

**The answer, briefly:** View All and Modify All are object permissions that ignore sharing for one object. View All Data and Modify All Data are system permissions that ignore sharing for every object in the org. Use the object-level pair. Modify All Data belongs to a countable number of named administrators and nobody else, and if your integration user holds it, that is a finding waiting to be written up.

## The object-level pair

View All and Modify All sit next to Read, Create, Edit and Delete on each object in a permission set. They do one thing: bypass the record gate for that object.

- **View All** grants Read on every record of that object regardless of org-wide defaults, [role hierarchy](https://trailassembly.com/role-hierarchy/) or [sharing rules](https://trailassembly.com/sharing-rules/).

- **Modify All** grants read, edit, delete and undelete on every record of that object, and allows transferring ownership of those records.

Both stay inside their object. Modify All on Case does nothing to Account, except that a detail record in a master-detail relationship follows its parent, so Modify All on the master reaches the detail as well. That is the one leak in the object boundary and it catches people.

## The org-wide pair

View All Data and Modify All Data live in System Permissions. They apply everywhere at once.

View All Data gives read access to every record of every object. Modify All Data gives read, edit, delete and undelete everywhere, plus two things people forget: it releases records locked by an approval process, and it permits mass transfer and mass delete that ordinary ownership would block. Enabling Modify All Data enables View All Data with it.

Neither one is a Setup permission. A user with Modify All Data can rewrite every record in the org and still cannot create a field, because that needs Customize Application. Data and metadata are separate privileges, and confusing them is how people conclude that Modify All Data is “not really admin”. It is admin over everything that matters to your customers.

## Why Modify All Data is almost never the right answer

Because it deletes your sharing model as a control. Every [org-wide default](https://trailassembly.com/org-wide-defaults/), every criteria-based rule, every carefully scoped role hierarchy stops applying to that user in one checkbox. Whatever your access design says, it now has an exception you cannot see from any of the screens where the design lives.

It also releases approval locks. If your finance approval process relies on records being uneditable while pending, Modify All Data quietly removes that guarantee for anyone who holds it.

The usual justifications do not survive contact with the alternatives. A data loading job needs Modify All on the three objects it loads, not on all of them. A reporting integration needs View All Data at worst, and View All on the specific objects at best. A support escalation user needs Modify All on Case. The honest case for Modify All Data is a time-boxed migration, with the permission removed the week it finishes.

## Find out who has it, today

```apex
SELECT Assignee.Name, Assignee.IsActive, PermissionSet.Name,
       PermissionSet.IsOwnedByProfile
FROM PermissionSetAssignment
WHERE PermissionSet.PermissionsModifyAllData = true
ORDER BY Assignee.Name
```

Swap in `PermissionsViewAllData` for the read-only version. Expect the result to be longer than you thought. Profiles appear in the same query because a profile is exposed as a permission set, so this catches the copy of “System Administrator” somebody cloned for a contractor years ago.

## What auditors ask about

Assignment changes land in the [Setup Audit Trail](https://trailassembly.com/who-changed-this-field/), and Security Health Check flags both org-wide permissions as high risk. The questions are predictable: who holds it, who approved it, when was it last reviewed, what would it take to remove. Write the answers in the permission set description, the only place they will still be readable in a year.

Field History Tracking and Field Audit Trail still record what these users changed, which is your only real detection control. They do not prevent anything.

## Frequently asked

**Does View All Data let a user see hidden fields?** No. Field-level security is a separate gate. The object permission that addresses fields is View All Fields, and it is scoped to one object.

**Can I mute Modify All Data?** A [muting permission set](https://trailassembly.com/permission-set-groups-and-muting/) can suppress it within a permission set group. It cannot touch the same permission granted by the profile or by another assignment, so muting is not a reliable way to claw it back.

**What about restriction rules?** Restriction rules are the platform’s one subtractive record control, designed to narrow what a user sees even when their other permissions are broad. Check their current supported objects before assuming they solve your case.

**Is Modify All Data needed to delete records in bulk?** No. Delete on the object plus record access covers everything the user can reach. It is only needed for records the user otherwise cannot see.

---

Source: https://trailassembly.com/view-all-modify-all-explained/
Trail Assembly — independent Salesforce write-ups.