Best Practices - Salesforce System Administrators

Why Salesforce System Administration Matters

Salesforce often holds sensitive operational data: student, employee, donor, financial, and research-related information. System administrators control who can access that data, how it is integrated with other systems, and how changes are deployed. Misconfigurations - rather than software flaws - are a leading cause of data exposure, privilege abuse, and compliance failures.

Careful configuration and ongoing governance by system administrators is critical to keeping Salesforce secure.

Common Risks

Category	Description	Key Controls (At a Glance)
Excessive Privileges & Misconfigured Sharing	Overly broad profiles, permission sets, or sharing rules expose more data and functions than intended.	Design role-based access; enforce least privilege; regularly review object/field access, sharing rules, and delegated administration.
Weak Authentication & Session Settings	Inadequate login protections allow account takeover or misuse of admin accounts.	Require SSO and MFA; restrict login IP ranges and hours where appropriate; configure secure session timeouts and inactivity locks.
Insecure Authentication	Poorly scoped OAuth tokens, API users, and connected apps can leak data or enable abuse.	To reduce redundancy with the "third-party apps and extensions" risk, use dedicated integration users; least-privilege permissions; restrict connected apps; review OAuth scopes and revoke unused tokens.
Unprotected Data (At Rest & In Transit)	Sensitive fields and files may be readable by more users or systems than necessary.	Classify data; restrict field-level access; use encryption (Shield or platform encryption); control report, export, and API access.
Unsafe Sandboxes & Change Management	Sandboxes with real data and weak controls can lead to inadvertent exposure or misuse.	Anonymize or subset data; limit sandbox access; use formal change management and deployment pipelines; restrict direct production changes.
Insufficient Monitoring & Logging	Lack of visibility into admin and user activity delays detection of misuse or compromise.	Enable login history and field history where appropriate; use Event Monitoring/Shield Event Monitoring; centralize and review logs.
Third-Party Apps & Extensions	Unvetted AppExchange packages, browser extensions, or integrations introduce new risks.	Inventory all apps and extensions. Establish an app review process; limit installation rights; prefer well-supported vendors; monitor access granted to apps.
Data Export & Reporting Risks	Large exports, reports, and data loader use can lead to data leakage or mishandling.	Restrict “Export Reports,” Data Loader, and bulk API access; use row-level security; monitor large exports and downloads.

Note:
The “Key Controls (At a Glance)” column is intended as a quick reference. Detailed expectations and implementation guidance are described in the Best Practices sections below.

General Best Practices

Design and Maintain a Least-Privilege Access Model

Use roles, profiles, and permission sets to grant only the access required for job responsibilities.
Prefer permission sets and permission set groups over highly permissive profiles; avoid using the System Administrator profile except where strictly necessary.
Configure organization-wide defaults (OWD), role hierarchy, sharing rules, and manual sharing so users see only the records they need.
Limit powerful permissions (e.g., Modify All Data, Author Apex, Customize Application, Modify Metadata) to a small, vetted set of admins.
Regularly review and recertify access: remove obsolete users, deactivate unused accounts, and revoke unnecessary permissions.

Harden Authentication & Session Settings

Prefer Single Sign-On (SSO) using SAML or OIDC integrated with your institutional identity provider.
Enforce Multi-Factor Authentication (MFA) for all users; require it for admins, integration users, and anyone with access to sensitive data or configuration.
Configure login IP ranges and login hours where possible, especially for privileged accounts and integration users.
Set session timeout and session security policies appropriate to data sensitivity; consider short timeouts and re-authentication for admin actions.
Disable or limit legacy or high-risk login methods (e.g., weak password policies, unmanaged OAuth logins) where alternatives exist.
Store integration credentials, API keys, and connected app secrets in Named Credentials or an approved secrets management service rather than hardcoding them in code or configuration, and rotate them at least annually.

Secure Integrations, Connected Apps, and APIs

Use dedicated integration user accounts for each integration rather than sharing human user accounts.
Grant integration users only the objects, fields, and system permissions they require; avoid broad “Modify All Data” access.
Carefully configure Connected Apps:
- Restrict login IP ranges, permitted users, and OAuth flows.
- Grant the minimum OAuth scopes required; avoid “full” or overly broad scopes where more granular ones suffice.
Periodically review and revoke unused refresh tokens, connected apps, and API keys.
Where feasible, route integrations through an institutional API gateway or integration platform for additional controls and monitoring.

Protect Sensitive Data

Classify data (e.g., public, internal, confidential, highly confidential) and map those classifications to Salesforce objects and fields.
Restrict field-level security (FLS) so sensitive fields (e.g., IDs, financial info, health-related data, PII) are visible only to users who need them.
Use record types and page layouts to limit which fields are displayed or editable for particular user groups.
Control report types, dashboards, and folder permissions to prevent inappropriate aggregation or exposure of sensitive data.
Where available and appropriate, use Salesforce Shield or platform encryption to encrypt data at rest, including sensitive custom fields and files.
Limit and monitor export capabilities (reports, Data Loader, bulk API); restrict permissions like “Export Reports” and “View All Data” to trusted roles.
Implement a backup solution that captures data and metadata rather than exports and sandbox copies which are snapshots.

Manage Sandboxes, Testing, and Change Management Safely

Use separate environments for development, testing, and production; avoid building or testing directly in production.
When copying production data into sandboxes:
- Minimize data copied to what is necessary for testing.
- Where possible, anonymize or mask sensitive data (especially PII and regulated data).
Restrict who can refresh, access, and manage sandboxes; remove unused sandboxes promptly.
Establish a formal change management process:
- Document changes.
- Use change sets, Salesforce DevOps tools, or CI/CD pipelines to deploy.
- Require peer review and testing for significant changes.
Control powerful tools such as Developer Console, Apex execution, and Metadata API access to a limited set of administrators.

Govern Third-Party Apps and Extensions

Establish a governance process for AppExchange and custom applications:
- Security and privacy review.
- Vendor risk assessment.
- Contractual and data protection requirements where appropriate.
Limit who can install or upgrade packages and manage connected apps.
Prefer well-supported, reputable vendors with strong security practices and clear documentation.
Periodically review installed packages, browser extensions, and integrations; remove those that are unused or no longer needed.

Monitor, Audit, and Respond

Enable and regularly review login history, setup audit trail, and relevant field history tracking.
Where available, use Event Monitoring / Shield Event Monitoring to log:
- Logins and authentication events
- Report exports and large data downloads
- API calls and bulk operations
- Administrative and configuration changes
Integrate Salesforce logs with your institutional SIEM to correlate with network and system events.
Establish alerting and incident response procedures for:
- Suspicious logins (e.g., unusual IPs, locations, times)
- Excessive failed logins or MFA failures
- Unexpected spikes in exports, API calls, or configuration changes
Run Security Health Check on a regular cadence against a custom baseline reflecting University standards, rather than the Salesforce default, to surface configuration drift in session, password, and login settings.

Educate and Coordinate with Stakeholders

Provide training and documentation for admins, developers, and power users on:
- Secure configuration practices
- Data classification and handling expectations
- Appropriate use of reports, exports, and integrations
Clearly assign roles and responsibilities among:
- Salesforce system administrators
- Data owners/stewards
- Security and compliance teams
Periodically review configurations with data stewards to confirm that access and sharing rules still align with business needs and policies.