Even with Delete checked at the Object-Level Security layer, several other factors can still prevent deletion. First, a Validation Rule could be blocking the deletion indirectly by failing on a related save action, though validation rules typically affect edits more than deletes directly. Second, and more commonly, the Opportunity may have related child records, such as Orders or Contracts, that prevent deletion due to referential integrity, requiring those related records to be removed first. Third, if Apex triggers or Flow automation include explicit logic that prevents deletion under certain conditions, such as blocking deletion of Opportunities past a certain stage, that automation would override the base permission. Fourth, the record might actually not be owned by this user despite their belief, since true ownership should always be verified directly on the record rather than assumed. The diagnostic approach is to attempt the deletion and read the EXACT error message Salesforce returns, since it usually identifies the specific blocking cause.

Object-Level Security controls whether a user can interact with a given object type AT ALL, through the Create, Read, Edit, and Delete permissions, acting as the first gate that determines whether any access to that object's records is even possible. Field-Level Security operates one layer deeper, controlling whether a SPECIFIC FIELD on an object the user already has some access to is Visible, Read-Only, or Hidden, independent of the object-level permissions. A concrete example requiring both: a Sales Rep needs Read and Edit at the Object-Level for Opportunity to access Opportunity records at all, but a sensitive field like Internal_Margin__c might need Field-Level Security set to Hidden for that same Profile, ensuring the Sales Rep can fully work with Opportunities while still never seeing the company's internal margin calculation on each deal.

Modify All Data grants the ability to view, edit, delete, and transfer ownership of every single record across every single object in the entire organization, while also bypassing most validation rule enforcement during these operations. This effectively grants nearly unrestricted data-level access throughout the org, which is the vast majority of what makes the System Administrator Profile powerful in the first place, the primary difference being that Modify All Data alone does not necessarily grant Setup configuration access like creating fields or modifying automation. Because of this near-total data access, granting Modify All Data to a user who does not genuinely need full data administration capability creates essentially the same risk profile as making them a System Administrator, which is why this permission should be treated with the same level of scrutiny and should generally be granted through a tightly scoped Permission Set to specific individuals rather than broadly on a Profile.

If a Login IP Range is configured on a Profile and a user's IP address subsequently changes, due to switching networks, home internet changes, mobile data usage, or VPN configuration changes, that user can be completely blocked from logging in through the standard interface with no way to resolve it themselves, since the IP restriction is enforced before authentication even completes. If this restriction is mistakenly applied to or affects the only System Administrator account, the organization could face a complete lockout with no internal path to fix the configuration, requiring an emergency support case with Salesforce to resolve. Experienced Admins protect against this by always maintaining at least one System Administrator Profile or a dedicated break-glass admin account with NO Login IP Range restrictions, ensuring there is always a verified path back into the org regardless of what restrictions are applied to other Profiles.

Standard Profiles like Standard User have certain System Permissions that are locked or have limited editability, particularly in older Salesforce editions, meaning they cannot be fully customized to match a specific organization's exact security requirements. Cloning a Standard Profile into a Custom Profile creates a fully independent copy with complete control over every single permission, while still starting from a sensible, Salesforce-tested baseline rather than building entirely from scratch. This also allows the Profile to be renamed to reflect an actual job function within the organization, such as "XYZ Company - Sales Rep," making the Profile list self-explanatory and far easier to manage and audit compared to having many users directly on generically-named Standard Profiles that do not reflect their actual organizational role.

This represents the common anti-pattern of using Profiles to handle individual or small-group exceptions rather than broad job functions, resulting in an unmanageable Profile list where it becomes increasingly difficult to understand what each Profile actually represents, audit security settings consistently, or onboard new Admins to understand the org's access model. The recommended modern approach is to consolidate down to a small number of broad, intentional Profiles organized around genuine job functions, typically well under 20 even for a large organization, and then use Permission Sets to layer small variations and exceptions on top of these broad baseline Profiles for specific individuals or smaller groups who need slightly different access. This dramatically reduces Profile count while still achieving the same precision of access control, since Permission Sets can be assigned and removed individually without needing a dedicated Profile for every minor permission variation.