Security

Why ‘Modify All’ Isn’t Just ‘View All’ Plus Editing

Ask who can see everything in the org and most teams check who holds View All Data. Ask who can change everything and the answer usually comes slower — because Modify All hides in more places than the profile page.

What each one actually is

Both permissions are sharing bypasses. View All Data reads every record regardless of sharing rules; Modify All Data reads, edits and deletes them — and quietly implies View All. The object-level variants (View All / Modify All per object) do the same within one object, and are easier to grant without ceremony. The risk difference is not “reading vs editing” — it is that Modify All turns a compromised account into a data-destruction event rather than a leak.

Where they hide

Profiles, permission sets, permission set groups — and the accumulation is the problem: a set granted for a migration in 2023 still grants it today, possibly to an integration account nobody watches, possibly MFA-exempt. The honest audit walks every grant path and asks who can currently exercise the permission, not just where it appears in metadata.

Auditing it without a week of spreadsheets

That walk — grants, assignments, exemptions, activity — is mechanical, which means software should do it. Horus Eye’s security rules grade each exposure by who can exercise it (an unassigned overprivileged set is low; the same set on an integration-pattern account is critical), report Modify All and View All separately in the Security Exposure measure, and can withdraw unneeded grants reversibly, step by approved step.

How broad permissions spread

Almost nobody grants Modify All Data on purpose to the person who ends up holding it. It spreads through cloning — a profile copied from an admin’s “temporarily,” a permission set built for an integration and reused for a contractor — and through permission set groups whose membership drifted from their name. The grant that mattered is usually three copies upstream of the user who alarms the auditor.

An audit you can finish this week

Work from the permission inward, not the user outward: list every profile and permission set that carries Modify All Data, View All Data, or per-object Modify All, then list who holds each, then ask the only question that matters — what job does this person do that requires editing records they do not own and cannot see otherwise? Most answers are “none; they needed one object” — which is the per-object fix. Replace broad grants with scoped permission sets, keep a short written register of the exceptions that survive with their reasons, and re-run the same pass quarterly so the register stays a page, not a chapter.

← Blogs

Related articles

Keep Reading

Put these ideas to work

Talk to a certified Agentforce and Salesforce architect.

Try Horus Eye Book a Strategy Session