Modify All Data permission enabled
Why is this an issue?
The Modify All Data user permission lets users read, edit, and delete every record in the org, bypassing every sharing rule, record-level security setting, and field-level security control. Granting it through a profile or a permission set creates serious risks:
Users can alter or delete records they should never be able to touch
Audit and compliance requirements (for example SOX, GDPR, HIPAA) may be violated
The blast radius of a compromised account or rogue insider grows dramatically
This permission should only be assigned to a small number of system administrators who genuinely need org-wide write access.
Examples
Example of an incorrect profile (Modify All Data enabled):
<Profile>
<userPermissions>
<enabled>true</enabled>
<name>ModifyAllData</name>
</userPermissions>
</Profile>
Example of an incorrect permission set (same problem):
<PermissionSet>
<label>Marketing User</label>
<userPermissions>
<enabled>true</enabled>
<name>ModifyAllData</name>
</userPermissions>
</PermissionSet>
Example of a correct permission set (object-level Modify All on specific objects only):
<PermissionSet>
<label>Marketing User</label>
<objectPermissions>
<object>Campaign</object>
<allowCreate>true</allowCreate>
<allowDelete>true</allowDelete>
<allowEdit>true</allowEdit>
<allowRead>true</allowRead>
<modifyAllRecords>true</modifyAllRecords>
<viewAllRecords>true</viewAllRecords>
</objectPermissions>
</PermissionSet>
How can I fix violations?
Confirm the permission is actually needed. Most users do not need org-wide write access; the most common reasons it appears are mistakes or shortcuts during initial setup.
Replace it with object-level permissions. Grant
Modify Allon the specific objects that genuinely require broad access throughobjectPermissions.Move elevated access into a permission set assigned to specific users, rather than baking it into a profile that everyone in a role inherits.
Use sharing rules to broaden record visibility instead of
Modify All Datawhenever the requirement is to see or edit a wider record set.
Configuration options
You can configure a comma-separated list of profile names to exclude from this check, and a separate list of permission set names to exclude. The profile or permission set named Admin is always excluded by default.
When should I disable this rule?
You may want to dismiss specific violations for:
Dedicated integration user profiles or permission sets where org-wide access is required for ETL, migration, or replication tooling.
If your org has admin-equivalent profiles or permission sets, prefer adding them to the configured exclusion lists rather than disabling the rule entirely.
Resources