SALESFORCE CLEANUP CHECKLIST

Why this is included: Active user licenses cost money, and accounts that are no longer in use represent an open door into your Salesforce org. If a former employee's credentials are compromised, an attacker can access customer data, manipulate records, or exfiltrate sensitive information. Salesforce does not automatically deactivate users when someone leaves the organization; this must be handled manually or through an automated offboarding process. Keeping inactive accounts active also inflates your license count and can skew user adoption metrics.

 

Details: Navigate to Setup > Users and filter by Last Login Date to identify accounts that have not logged in within 90 days. Cross-reference this list with HR offboarding records to confirm which users have left the organization. Before deactivating a user, review their owned records across Leads, Contacts, Accounts, Opportunities, and Cases. Use the Mass Transfer tool or Data Loader to reassign ownership in bulk. Note that Salesforce does not allow user deletion; users can only be deactivated, which preserves historical activity and record associations.

 

Dos:

• Do set up an automated offboarding workflow that triggers deactivation when an employee is marked as terminated in your HR system.

• Do reassign records to an active user, a queue, or a designated "Unassigned" holding account before deactivating.

• Do document the deactivation date and reason for audit trail purposes.

• Do review Chatter groups, approval processes, and escalation rules that reference the deactivated user, as these can break silently.

 

Don'ts:

• Don't deactivate a user without first reassigning their records — orphaned records become inaccessible to the team and can fall out of reports.

• Don't assume that deactivating a user revokes their API access immediately if they have active OAuth tokens — revoke those separately.

• Don't skip reviewing whether the user is referenced in any automation (Flows, Process Builder, Workflow Rules) as the named user in an action.

Why this is included: The principle of least privilege states that users should only have access to the data and functionality they need to perform their job — nothing more. In practice, Salesforce orgs accumulate permission bloat over time as one-off access requests are granted and never revoked. A sales rep who was temporarily given admin-level access to troubleshoot an issue may maintain that access indefinitely if not reviewed. Overly permissive access increases the blast radius of any security incident and creates compliance risk under frameworks like SOC 2, ISO 27001, and GDPR.

 

Details: Start by auditing profiles — the baseline permission set assigned to every user. Profiles should be as restrictive as possible, with elevated access granted through Permission Sets rather than baked into the profile. Review each profile's object permissions, field-level security, app access, and system permissions. Pay particular attention to "View All Data," "Modify All Data," "Manage Users," and "Author Apex" — these are high-risk permissions that should be limited to system administrators. Permission Set Groups, introduced in Salesforce Spring '20, allow you to bundle related Permission Sets into a single assignable unit, making access management more scalable and auditable.

 

Dos:

• Do use Permission Sets and Permission Set Groups to grant elevated access rather than creating multiple profiles.

• Do conduct a formal access review at least twice per year, ideally aligned with your organization's security audit cycle.

• Do use the Permission Set Assignment report and Profile comparison tools in Setup to identify discrepancies.

• Do document the business justification for any elevated permissions, especially those granting access to sensitive objects.

 

Don'ts:

• Don't use the System Administrator profile as a catch-all for users who need "a little extra access."

• Don't grant "View All" or "Modify All" on sensitive objects (e.g., Contracts, Financial Records) without a documented business need.

• Don't leave deprecated profiles active — consolidate and retire them to reduce complexity.

• Don't overlook field-level security; a user may not have object-level access but could still see sensitive fields through related lists or reports.

Why this is included: Login and session security settings are foundational controls that protect your org from unauthorized access. Salesforce has mandated multi-factor authentication (MFA) for all users since February 2022, but enforcement must still be explicitly configured — it is not automatic. Session settings such as timeout duration, clickjack protection, and HTTPS enforcement can drift from organizational standards as admins make ad hoc changes. A misconfigured session policy can expose your org to session hijacking, credential stuffing, or brute-force attacks.

 

Details: Navigate to Setup > Identity > Session Settings to review timeout values, IP restrictions, and security-related toggles. Confirm that MFA is enforced via Setup > Identity > MFA and Verification Methods — not just enabled, but required. Review Trusted IP Ranges on each profile to ensure they are not set to overly broad ranges. Check Login Hours restrictions on profiles to limit access to business hours where appropriate. Align all settings with your organization's security policy and any applicable compliance requirements.

 

Dos:

• Do enforce MFA for all human users — use the MFA Enforcement Roadmap in Setup to track compliance.

• Do set session timeout to 2 hours or less for users with access to sensitive data.

• Do enable "Lock sessions to the IP address from which they originated" to reduce session hijacking risk.

• Do review and restrict Login IP Ranges on profiles, especially for integration users.

 

Don'ts:

• Don't rely on single-factor authentication for any user, including internal employees.

• Don't set session timeout to "Never" — this leaves sessions open indefinitely if a user forgets to log out.

• Don't allow login from all IP addresses for privileged users such as system administrators.

• Don't overlook the "High Assurance Session" requirement for sensitive operations — configure this for actions like accessing encrypted fields or running data exports.

Why this is included: Integration users are often granted elevated permissions to facilitate data synchronization between Salesforce and external systems such as ERPs, marketing platforms, or data warehouses. Because these accounts are not tied to a human user, they are frequently overlooked during access reviews. A compromised integration user credential can provide persistent, automated access to your entire org. Additionally, integration users tied to decommissioned systems continue to consume API call limits and represent unnecessary risk.

 

Details: Review all users with the "API Only" profile or those flagged as integration users. For each, confirm the connected system is still active, the permissions are scoped to only the objects and fields required for the integration, and credentials are rotated on a defined schedule (e.g., every 90 days). Use Named Credentials in Salesforce to manage authentication for outbound callouts, avoiding hardcoded credentials in Apex code or configuration. Review API usage logs to identify integration users with unexpectedly high or low call volumes, which may indicate misconfiguration or dormancy.

 

Dos:

• Do use dedicated integration user accounts — never use a named employee's account for system integrations.

• Do apply the principle of least privilege to integration users, granting access only to the specific objects and fields the integration requires.

• Do use Named Credentials and OAuth 2.0 flows where possible to avoid storing credentials in code.

• Do monitor API usage per user to detect anomalies that could indicate unauthorized access.

 

Don'ts:

• Don't leave integration users active for systems that have been decommissioned or replaced.

• Don't grant System Administrator profile to integration users — create a custom profile with only the required permissions.

• Don't hardcode usernames and passwords in Apex classes, custom settings, or configuration files.

• Don't skip rotating credentials for integration users — treat them with the same rigor as privileged human accounts.

Why this is included: Salesforce's sharing model is layered and complex — Organization-Wide Defaults (OWD), the role hierarchy, sharing rules, and manual sharing all interact to determine who can see and edit which records. As organizations grow, restructure, or acquire new teams, the role hierarchy and sharing rules can fall out of sync with the actual organizational structure. This can result in users seeing records they shouldn't (overexposure) or being unable to access records they need (underexposure), both of which create operational and compliance problems.

 

Details: Start by reviewing OWD settings for each object under Setup > Sharing Settings. OWD defines the baseline access level — Private means only the record owner and users above them in the role hierarchy can access the record, while Public Read/Write means everyone can. For sensitive objects, OWD should generally be set to Private. Next, audit the role hierarchy to confirm it reflects the current organizational structure — outdated roles can grant unintended record visibility. Review all sharing rules (criteria-based and ownership-based) to identify any that are overly broad or no longer relevant.

 

Dos:

• Do set OWD to the most restrictive setting that still allows the business to operate, then open access up through sharing rules and role hierarchy as needed.

• Do review the role hierarchy whenever there is a significant organizational change (restructuring, acquisition, team merger).

• Do use criteria-based sharing rules to grant access based on record attributes rather than manual shares, which are harder to audit.

• Do periodically run a sharing audit to validate that users have the expected level of access.

 

Don'ts:

• Don't set OWD to Public Read/Write for sensitive objects like Contracts, Cases, or custom financial objects.

• Don't rely on manual shares as a long-term access solution — they are difficult to audit and do not scale.

• Don't leave obsolete roles in the hierarchy — they can inadvertently grant record visibility to users in child roles.

• Don't overlook Territory Management if your org uses it — territory assignments interact with the sharing model in ways that can be non-obvious.

Why this is included: Connected Apps allow external applications to authenticate to Salesforce via OAuth, enabling integrations with tools like Slack, marketing automation platforms, and custom web apps. Over time, Connected Apps that are no longer in use can retain active OAuth tokens that provide persistent access to your org without requiring re-authentication. This is a significant security risk, particularly for orgs that have undergone system migrations, vendor changes, or employee departures where personal OAuth tokens were used.

 

Details: Navigate to Setup > Connected Apps > Connected Apps OAuth Usage to see which apps have active tokens and how many users have authorized them. Revoke tokens for apps that are unrecognized, inactive, or no longer in use. Review the policies on each Connected App — specifically the "Permitted Users" setting (which should be "Admin approved users are pre-authorized" rather than "All users may self-authorize" for sensitive apps) and IP relaxation settings. Ensure that all active Connected Apps have appropriate scopes defined — avoid granting "Full Access" (full) scope unless absolutely necessary.

 

Dos:

• Do review Connected Apps OAuth Usage at least quarterly and revoke tokens for inactive or unrecognized apps.

• Do restrict Connected App access to approved users only, using profiles or permission sets to control who can authorize the app.

• Do define the minimum required OAuth scopes for each Connected App.

• Do set IP restrictions on Connected Apps to limit access to known IP ranges where possible.

 

Don'ts:

• Don't allow users to self-authorize Connected Apps without admin approval for apps that access sensitive data.

• Don't grant "Full Access" OAuth scope unless the integration genuinely requires it — use narrower scopes like api, refresh_token, or offline_access.

• Don't leave Connected Apps active for vendors or systems that are no longer part of your technology stack.

• Don't overlook personal OAuth tokens created by individual users — these can persist even after the user is deactivated.