System Administrator
System Administrator is the default Salesforce profile that grants the highest level of access to an org: every Setup page, every record across every object, every administrative permission, and the ability to modify metadata, write Apex, manage users, and change configuration.
Definition
System Administrator is the default Salesforce profile that grants the highest level of access to an org: every Setup page, every record across every object, every administrative permission, and the ability to modify metadata, write Apex, manage users, and change configuration. The profile ships with every Salesforce edition and is the starting point for the first user provisioned on a new org. From there, the System Administrator is responsible for managing every other user, setting up the data model, building automation, configuring security, and operating the platform on behalf of the business.
The profile carries significant blast radius: a System Administrator can delete every record in the org, modify or remove every metadata component, change every user permissions, and export data wholesale. Mature orgs treat System Administrator access as a privileged credential, granted sparingly, audited regularly, and protected through multi-factor authentication and login IP restrictions. The role is critical but the privilege level should not be the default for everyone on the admin team; permission sets and narrower profiles often suffice.
System Administrator in Salesforce: blast radius, governance, and the modern alternatives
What System Administrator profile actually grants
The System Administrator profile grants every administrative permission Salesforce ships: View All Data, Modify All Data, Customize Application, Manage Users, Manage Profiles and Permission Sets, Manage Sharing, Manage Billing, View Setup and Configuration, Author Apex, Modify Metadata Through Metadata API Functions, Reset User Passwords and Unlock Users, and roughly 50 others. The profile also grants Read, Create, Edit, and Delete on every standard object plus View All and Modify All. Field-level security is universal: every field is editable. Sharing rules are bypassed: the System Administrator sees every record regardless of ownership or sharing settings. In short, the profile has no platform-level constraints; the limits are the laws of physics (Salesforce shipped this version, the org has these features licensed).
When System Administrator access is appropriate
System Administrator should be granted to a small number of users who genuinely need org-wide configuration access: the lead admin, the platform architect, an emergency backup admin (often the same person manager). The lead admin owns daily configuration changes. The platform architect makes structural decisions. The emergency backup ensures continuity when the lead admin is unavailable. For most other admin-team members, narrower roles are appropriate: a Sales Operations admin who manages opportunities and sales reports but does not touch metadata, a Service Operations admin who configures Cases and Knowledge but does not change profiles, a Data admin who handles imports but does not write Apex. Mature orgs configure these narrower roles through permission set groups assigned to standard or customized profiles, keeping System Administrator access truly privileged.
Security risk and the principle of least privilege
System Administrator access is a security risk because the blast radius is the entire org. A compromised System Administrator account can delete every record, export every Personal Data field, modify every automation, and grant access to external attackers. The Salesforce platform mitigates this with several layers: multi-factor authentication (required by default for all logins in 2026), login IP restrictions (the profile can restrict logins to specific IP ranges), session security settings (high-assurance sessions required for certain administrative actions), and Setup Audit Trail (logs every configuration change). Mature orgs enforce additional layers: hardware-bound MFA, just-in-time admin elevation through tools like Saviynt or BeyondTrust, mandatory session timeout. Treat System Administrator credentials as high-value assets requiring continuous protection.
Standard System Administrator vs custom Admin profiles
Salesforce ships the System Administrator profile and also lets admins clone it to create custom admin profiles with narrower permissions. The pattern: clone System Administrator, remove the Modify All Data permission (which removes the bypass of sharing rules), remove specific admin-only features the role does not need, save as Sales Cloud Admin or Service Cloud Admin or similar. The custom profile retains most of the configuration power but operates within the org normal sharing model. This pattern lets orgs grant configuration access without granting view-everything access. The standard System Administrator profile is the one Salesforce maintains; custom admin profiles are the customer responsibility to maintain across Salesforce releases (new permissions added in each release may need to be added to the custom profile).
Permission set groups as the modern alternative to wide profiles
Modern Salesforce administration favors permission set groups over broad profiles. The pattern: assign every user a minimal-permissions profile (Standard User or a narrow custom profile), then grant additional capabilities through permission set groups (Sales Admin, Service Admin, Data Admin). Users carry multiple permission set groups as their responsibilities evolve. The advantage over profile-based admin grants is that permission set groups are composable, easier to audit, and easier to revoke when a user changes roles. The standard System Administrator profile remains for the small group that needs full access; everyone else gets a narrow profile plus targeted permission set groups. Mature orgs invest in building a clean permission set group library and reuse it across the team rather than maintaining many overlapping admin profiles.
System Administrator audit, rotation, and shared-account risks
Treat System Administrator accounts as production credentials. Audit System Administrator activity through the Setup Audit Trail weekly. Rotate System Administrator passwords on a defined schedule (90 days is common). Never share System Administrator credentials between users; the audit trail attributes every action to the user identity that performed it, and shared credentials destroy the audit story. For service accounts that need System Administrator capabilities (integration users, data migration accounts), use dedicated profiles with the specific permissions needed, not the standard System Administrator profile. Mature orgs run an annual access review where every System Administrator-permissioned user is reviewed and either re-justified or downgraded to a narrower role. Without active management, System Administrator access creeps as admins inherit permissions during ad-hoc troubleshooting.
Governing System Administrator access in Salesforce
Managing System Administrator access well is more about restraint than configuration. The four-step routine covers: limit System Administrator grants to a small named group, build narrower admin profiles for the broader admin team, configure security layers (MFA, IP restrictions, session settings), and audit System Administrator activity weekly through the Setup Audit Trail. Each step compounds the security posture; together they let an org operate with strong administrative governance while still moving fast on configuration changes.
- Limit System Administrator grants to a small named group
Identify the users who genuinely need full System Administrator access: the lead admin, the platform architect, an emergency backup. Document each grant in the access registry with the user, the date, the business justification. For every other admin-team member, plan a narrower role. Resist the pressure to grant System Administrator to everyone who asks; broad grants are easy to give and hard to revoke later. Aim for fewer than five System Administrators in a mid-sized org; very large orgs may have ten, never more without strong justification.
- Build narrower admin profiles for the broader admin team
For each admin-team role (Sales Operations Admin, Service Operations Admin, Data Admin, Release Engineer), build a custom profile cloned from System Administrator with the unneeded permissions removed. Remove Modify All Data if the role does not need to bypass sharing. Remove Customize Application if the role does not modify metadata. Save the profile and assign it to the right users. Add permission set groups on top for specific responsibilities that exceed the base profile. Document each profile intent and the rationale for each permission decision.
- Configure security layers
Require multi-factor authentication for every System Administrator account (Setup, Identity Verification, MFA settings). Configure login IP restrictions on the System Administrator profile so the credential is only usable from approved IP ranges. Set session security to High Assurance Required for sensitive actions (Setup pages, Apex execution). Enable Setup Audit Trail email notifications for any System Administrator-only configuration changes so the security team gets visibility. Each layer adds friction for attackers; combined, they make compromise much harder.
- Audit System Administrator activity weekly
Open Setup, View Setup Audit Trail, and filter to actions by System Administrators in the past week. Review the changes for anything unexpected: a permission set assigned to a non-admin, a sharing rule modified outside business hours, a profile cloned without explanation. Investigate anomalies. Rotate the review responsibility across the admin team so the discipline persists. Track the count of System Administrators in the org; if the number grows quietly, push back on the latest grant and confirm it is truly needed. Run an annual full review where every grant is re-justified.
- System Administrator access has org-wide blast radius. A compromised account can delete every record, export Personal Data, and grant access to attackers. Treat the credential as high-value.
- Granting System Administrator broadly is easy; revoking is hard. Users get used to the access and push back when downgraded. Set the bar high at grant time.
- Custom admin profiles cloned from System Administrator drift over Salesforce releases. New permissions added in each release may need to be reviewed and added to the custom profile.
- Service accounts should not use the standard System Administrator profile. Build dedicated profiles for integration users with only the permissions the integration needs; this limits blast radius if the credential leaks.
- Shared System Administrator credentials destroy the audit trail. Every action attributes to the shared identity; never share credentials across users.
Trust & references
Straight from the source - Salesforce's reference material on System Administrator.
- Standard ProfilesSalesforce Help
- Multi-Factor AuthenticationSalesforce Help
- Setup Audit TrailSalesforce Help
Hands-on resources to go deeper on System Administrator.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is System Administrator?
Q2. Who should have it?
Q3. What's a common mistake?
Discussion
Loading discussion…