A standard profile ships with every Salesforce org — System Administrator, Standard User, Read Only, etc. — and cannot be deleted. A custom profile is one you create by cloning a standard profile and tailoring its permissions. Both behave identically once assigned to users; the practical differences are around what you’re allowed to change, whether the profile can be deleted, and how upgrades affect them.
Side-by-side
| Dimension | Standard Profile | Custom Profile |
|---|---|---|
| Where it comes from | Shipped with the org by Salesforce | You clone a standard profile and modify |
| Deletable? | No | Yes (if no users are assigned) |
| Renameable? | No | Yes |
| Fully editable? | Mostly — some core behaviors are locked | Yes — everything inherited from the clone source is editable |
| Inherits new permissions in upgrades? | Sometimes — Salesforce may auto-add or rename permissions in releases | Same — release-time tweaks can also affect custom profiles |
| Common examples | System Administrator, Standard User, Read Only, Marketing User | ”Sales Rep – Minimum”, “API Integration”, “Customer Support Tier 1” |
| License binding | Fixed by Salesforce | Inherited from the cloned standard profile |
What you can’t do on a standard profile
- Delete it.
- Rename it.
- Remove certain platform-defining permissions (System Administrator can never lose “Customize Application” or “Modify All Data” — those are part of what the role means).
- Change its associated license type.
Most field-level security toggles, object CRUD checkboxes, and tab visibility are editable on a standard profile in modern releases, but you should generally avoid heavy edits to standard profiles. Instead, clone them.
What you can do on a custom profile
Anything the cloned source supports — toggle CRUD, FLS, tab visibility, app visibility, page layout assignments, record type assignments, login hours, login IP ranges, custom permissions, system permissions, Apex class access, Visualforce page access. You can also delete the profile (when no users are assigned) and rename it.
Why custom profiles exist
The standard System Administrator is too powerful for most non-admin users. The standard Standard User is often too permissive (it grants Create on Account and Opportunity, which many orgs want to restrict to specific roles). Cloning and editing lets you craft a baseline for each role without modifying the shipped profiles — which keeps your org closer to the out-of-the-box configuration and makes upgrades cleaner.
Modern best-practice nuance
Salesforce’s recent direction is to keep the profile minimal and add power via permission sets. So in a well-maintained org you’ll see one or two narrow custom profiles per license type, plus dozens of permission sets that compose access on top. The “clone a standard profile and stuff everything into it” pattern from the 2010s has been replaced.
Common interview follow-ups
- Can I delete the System Administrator profile? No — it’s standard and protected.
- If Salesforce adds a new system permission in a release, does it appear on standard profiles? Yes, typically with a sensible default (off for most, on for System Administrator). Salesforce announces these changes in release notes.
- Why would I clone instead of just editing the standard profile? Reversibility, change management, and to avoid coupling your customizations to a name Salesforce controls.
- Does cloning copy permission set assignments? No — assignments are per user, not per profile.
Verified against: Salesforce Help — Standard Profiles and Manage Profiles. Last reviewed 2026-05-17.