# Best Practices - Salesforce System Administrators ![eyeglasses laying on top of salesforce logo on desk](/sites/g/files/omnuum12036/files/styles/hwp_1_1__360x360_scale/public/2026-07/salesforce.jpeg?itok=pbkcG7Lc) ## 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 SortCategoryDescriptionKey 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 Integrations & Connected Apps Poorly scoped OAuth tokens, API users, and connected apps can leak data or enable abuse. 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. 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. #### 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. #### 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 - Periodically review health checks, security settings, and recommended updates from Salesforce. #### 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. ## Related Resources - [University Standards](/apply-standards "Apply Standards") - [OWASP Top 10 (Critical Web Risks)](https://owasp.org/www-project-top-ten/) - [CISA 'Secure by Design (Software Architecture)](https://www.cisa.gov/securebydesign) - [Salesforce Security Guide](https://help.salesforce.com/s/articleView?id=xcloud.security_secure_your_org.htm&type=5)