View All, Modify All and Administrative Permissions

Why This Topic Matters for the Advanced Administrator Exam
The Salesforce Certified Advanced Administrator exam dedicates a significant portion of its weighting to Security and Access. Within that domain, the examiners love to test whether you truly understand the difference between granting access through the sharing model and granting access that bypasses the sharing model entirely. View All, Modify All, and the system-level administrative permissions (View All Data, Modify All Data, Manage Users, and friends) are the tools that override Organization-Wide Defaults, role hierarchy, sharing rules, teams and manual shares. Because they are so powerful, questions in this area usually revolve around two themes: (1) which permission is the minimum needed to accomplish a requirement, and (2) which permission would over-grant access and therefore violate the principle of least privilege. If you can keep the scope (one object vs. whole org) and the strength (read vs. read/edit/delete/transfer/approve) straight in your head, you will pick up easy marks.

What These Permissions Are
Salesforce controls access in layers. Object permissions decide what a user can do with an object in general; the sharing model decides which individual records the user can reach; field-level security decides which fields are visible or editable. Normally the object permissions Read, Create, Edit and Delete only apply to records the user can already see through the sharing model. View All and Modify All are special object permissions that cut through the sharing layer.

View All (object level)
Granted per object on a profile or permission set. It gives the user read access to every record of that object regardless of OWD, role, sharing rules or manual sharing. Checking View All automatically checks Read. It does not allow editing or deleting records the user does not otherwise have access to. Typical use case: a compliance analyst or report writer who needs to see every Case in reports and list views, but must never change them.

Modify All (object level)
Also granted per object. It grants read, edit, delete, transfer and approve on every record of that object regardless of sharing. Checking Modify All automatically checks Read, Create, Edit, Delete and View All. Because it includes Delete and Transfer on records owned by others, it is the permission that lets a user mass transfer, mass delete, merge or approve records they do not own and are not above in the role hierarchy. Typical use case: a sales operations lead who manages Opportunity data quality across all regions, or a support team lead who must be able to delete or reassign any Case.

Administrative (system) permissions
These live in the System Permissions / Administrative Permissions section of profiles and permission sets and are org-wide rather than object-specific. The most heavily tested ones are:
• View All Data: read access to all records of all objects, regardless of sharing. Think of it as View All on every object at once.
• Modify All Data: create, read, edit, delete, transfer and approve all records of all objects, regardless of sharing. Selecting it automatically grants View All Data. It also unlocks admin-only behaviors such as viewing and undeleting any record in the org-wide Recycle Bin, editing records locked by an approval process when the process is set to 'Administrators ONLY can edit records during the approval process', and importing or loading data with arbitrary owners.
• View All Users: see all user records even when the User object OWD is Private.
• Manage Users: create, edit, deactivate, freeze and unlock users, reset passwords, and assign profiles and roles.
• Manage Profiles and Permission Sets and Assign Permission Sets: the first lets a user edit profiles and permission sets; the second only lets them assign existing permission sets.
• Customize Application: build and modify custom objects, fields, page layouts, record types and similar metadata. It depends on View Setup and Configuration.
• View Setup and Configuration: read-only visibility of the Setup menu.
• Manage Sharing and Manage Roles: edit sharing settings and sharing rules, or edit the role hierarchy.
• Transfer Record: transfer ownership of records the user has access to; combined with Modify All it enables transferring any record.
• Modify Metadata Through Metadata API Functions, Author Apex, API Enabled, Weekly Data Export, Manage Public List Views, Manage Public Reports: narrower administrative capabilities that appear as distractors or as the 'least privilege' correct answer.

How It Works in Practice
Picture the access funnel. The Organization-Wide Default sets the baseline (Private, Public Read Only, Public Read/Write). Role hierarchy, sharing rules, manual sharing, teams and Apex managed sharing can only open up access and can grant at most Read/Write; they can never grant Delete on another user's record. When a requirement says a user needs to see, edit, delete, transfer or approve records regardless of who owns them, the sharing model cannot get you there without changing access for everyone; that is when View All or Modify All on the object is the correct tool.

Some important behaviors to remember:
• View All and Modify All still respect field-level security. A user with Modify All on Opportunity who has no FLS on the Amount field cannot see Amount. Likewise, View All Data and Modify All Data do not override FLS or page layout restrictions.
• Reports and dashboards honor sharing. If a report needs to show all records of an object to a non-admin, that user needs View All on the object (or View All Data), or the dashboard must run as a user who has it.
• The Delete object permission alone only works on records the user owns, records below them in the role hierarchy, or records explicitly shared with Full Access. To delete anyone's record, the user needs Modify All on that object or Modify All Data.
• Mass Transfer of records owned by others requires Modify All on the object (or Modify All Data) together with the Transfer Record permission.
• Approval processes: Modify All on the object lets a user approve or reject any approval request for that object, and Modify All Data lets a user edit locked records when the process is configured to allow administrators only.
• Permissions are additive. A user gets the union of their profile and all assigned permission sets and permission set groups. You cannot use a permission set to remove View All or Modify All granted by a profile (though muting permission sets within a permission set group can mute permissions granted by that group).
• Permission dependencies are enforced: selecting Modify All Data auto-selects View All Data; selecting Modify All on an object auto-selects all its CRUD permissions and View All; Customize Application requires View Setup and Configuration.
• Best practice is to grant View All and Modify All at the object level via permission sets rather than handing out View All Data or Modify All Data, which expose every object in the org including sensitive HR or finance custom objects. Reserve Modify All Data for true system administrators, and consider Delegated Administration for user management tasks that do not justify Manage Users.

How to Answer Exam Questions on This Topic
Work through a repeatable checklist:
1. Identify the scope. Does the requirement mention one object (Cases, Opportunities, a custom object) or all data in the org? One object points to View All / Modify All on that object; all data points to View All Data / Modify All Data.
2. Identify the strength. Read only ⇒ View All. Edit, delete, transfer, approve or 'manage' ⇒ Modify All.
3. Look for the words 'regardless of ownership', 'all records', 'not in the role hierarchy', 'without changing sharing for other users'. These signal that OWD changes, sharing rules and role changes are distractors because they would affect other users or cannot grant Delete.
4. Apply least privilege. If two answers would both technically work, choose the narrower one: object-level over org-level, permission set over profile change, Assign Permission Sets over Manage Profiles and Permission Sets, View Setup and Configuration over Customize Application.
5. Check for the hidden FLS or layout trap. If the user has Modify All but still cannot see a field, the answer is field-level security, not another administrative permission.
6. Check who is affected. Changing the OWD or adding a sharing rule affects groups of users; View All/Modify All on a permission set affects only the assigned users.

Worked Mini-Scenarios
• A compliance officer must view every Case in reports but must not edit any. Answer: View All on Case via a permission set. Distractors: View All Data (too broad), Modify All (too strong), OWD Public Read Only on Case (affects everyone).
• A sales ops user needs to delete duplicate Leads owned by any rep. Answer: Modify All on Lead. Distractor: Delete permission alone (only works on own or subordinate records); sharing rule (cannot grant Delete).
• A user with Modify All on Opportunity cannot see the Discount field. Answer: adjust field-level security; no additional permission fixes this.
• A help desk analyst must reset passwords and unlock users but should not create fields. Answer: Manage Users (or Delegated Administration), not Modify All Data or Customize Application.
• A manager must reassign ownership of any Account in the org. Answer: Modify All on Account plus Transfer Record.
• An admin must edit an Opportunity locked in approval. Answer: Modify All Data, and the approval process must allow administrators to edit during approval.

Exam Tips: Answering Questions on View All, Modify All and Administrative Permissions
• Memorize the two axes: scope (object vs. org) and strength (view vs. modify). Four permissions, four boxes: View All, Modify All, View All Data, Modify All Data.
• 'Modify All' always includes transfer and approve, not just edit and delete. Expect a question built on that nuance.
• Sharing rules and role hierarchy can never grant Delete; only ownership, Full Access, Modify All, or Modify All Data can. If the requirement includes deleting others' records, eliminate every sharing-based answer immediately.
• View All/Modify All/View All Data/Modify All Data never bypass field-level security. When the symptom is a missing or read-only field, the fix is FLS.
• When the question stresses 'minimum access' or 'security best practice', pick the object-level permission in a permission set over any org-wide administrative permission or profile edit.
• Know the auto-selection rules: Modify All Data selects View All Data; Modify All on an object selects Read, Create, Edit, Delete and View All; View All selects Read.
• View All Users is about the User object; View All Data is about records. Do not confuse them when the scenario is about seeing deactivated or other business-unit users.
• Manage Users vs. Delegated Administration: if the scenario is a regional manager who should only manage users in specific roles and profiles, Delegated Administration is the least-privilege answer.
• Reports respect sharing: 'users cannot see all records in a report' is answered by View All on the object, not by report folder sharing.
• Watch for 'affects other users' distractors such as changing OWD to Public Read/Write or adding everyone to a sharing rule when only one person needs the access.
• If the stem says the user is a 'system administrator' already, the answer is usually not a permission at all; look for FLS, record type, page layout, or validation rule causes instead.

Master these distinctions and you will be able to dissect any View All, Modify All or administrative permission question quickly, eliminate the over-broad and under-powered options, and land on the least-privilege answer the exam is looking for.