Salesforce user management is the practice of controlling who can log in, what they can do once inside, and which records they can see, across the whole lifecycle from access request to offboarding. Done well it is invisible. Done badly it surfaces as a departed employee who still has a login, an admin with permissions nobody approved, or an audit finding nobody can answer.
This guide covers how Salesforce access actually works, seven practices that keep it under control, how to audit what a user can really do, and checklists for onboarding and offboarding.
What Is Salesforce User Management?
User management covers four responsibilities: provisioning access when someone joins or changes role, granting the right functional permissions and record visibility, monitoring how that access is used, and revoking it promptly when it is no longer needed.
It applies to more than employees. A complete picture includes internal users, external users on Experience Cloud sites, temporary users such as contractors and auditors, and integration users that connect other systems. Integration users are the most commonly overlooked, because nobody owns them and they often hold far broader permissions than any human in the org.
How Salesforce User Access Works
Salesforce splits access into two questions that are governed by different mechanisms, and confusing them is the root of most access problems.
- What can this user do? Functional permissions, controlled by licences, profiles, permission sets and permission set groups.
- Which records can this user see? Record visibility, controlled by organization-wide defaults, the role hierarchy and sharing rules.
Adding someone to a role does not grant them the ability to edit Opportunities. Granting the edit permission does not let them see anyone else’s records. You usually need both.
One distinction worth pinning down: user licences versus permission set licences. A user licence is assigned to the user and sets the ceiling on what they can ever be granted, which is why a Salesforce Platform user cannot be given access to standard CRM objects no matter which permission set you assign. A permission set licence sits on top and unlocks a specific capability, such as CRM Analytics or Identity, and is assigned separately. If a permission set will not save, or a permission is greyed out, the licence is usually the reason rather than the permission set itself.
Best Practices for Salesforce User Management
Seven practices, ordered roughly the way a user moves through their lifecycle.
1. Assign Role-Based Access
Grant access based on job function rather than individual. When someone changes role, you swap the assignment instead of unpicking bespoke permissions nobody documented.
Start by mapping personas: a sales rep needs Leads and Opportunities but not finance data; a support agent needs Cases but not the sales pipeline. Then decide which mechanism delivers each part. Use the role hierarchy for record visibility, so managers see their team’s records, and keep it aligned to reporting lines rather than to job titles, since the hierarchy exists to open up record access rather than to model the org chart.
2. Use Permission Sets as the Primary Access Model
Older guidance treats profiles as the main mechanism and permission sets as exceptions. Salesforce has moved decisively the other way, and has announced it is retiring system and object permissions on profiles. Build for that direction now.
The workable pattern is a thin profile providing only the baseline every user of that licence type needs, with everything else delivered through permission sets. Group those into permission set groups by persona, so onboarding a new sales rep is one assignment rather than nine.
Muting permission sets let you reuse a permission set inside a group while switching off specific permissions for that group only. One caveat that catches people out: muting applies only within the group. If the user also holds that permission through their profile, another permission set, or a different group, they keep it.
For temporary access, set an expiration date on the permission set assignment rather than relying on someone remembering to remove it. Contractor, auditor and cover arrangements should expire automatically.
3. Conduct Regular Permission Audits
Access accumulates. People change roles and keep the old permissions, projects end and their temporary grants persist, and integration users quietly hold administrator-level rights.
A useful audit covers five things: effective access for a sample of users in each persona, dormant accounts with no recent login, users holding high-risk permissions such as Modify All Data or Manage Users, temporary assignments that should have expired, and integration users measured against what their integration actually needs.
Review quarterly for privileged access and at least twice a year for everyone else, and keep the evidence. In a regulated environment an audit you cannot produce a record of did not happen.
4. Enable Multi-Factor Authentication with Supported Methods
Salesforce enforces MFA for direct UI and single sign-on logins for all employee users, across production and sandbox orgs, as of June 2026. This is no longer a recommendation to plan for.
Use methods Salesforce actually accepts. Salesforce supports four verification methods: built-in authenticators such as Touch ID, Face ID and Windows Hello; physical security keys; the Salesforce Authenticator app; and third-party authenticator apps. Critically, Salesforce does not allow one-time passcodes delivered by email, SMS or phone call, or security questions. The restriction is deliberate, because phone numbers can be intercepted through SIM swapping and email accounts can be compromised. This applies whether you use native Salesforce MFA or an SSO provider.
Prioritise phishing-resistant methods. Salesforce names built-in authenticators and security keys as the phishing-resistant options and recommends requiring them. It requires phishing-resistant MFA for users holding the System Administrator profile or certain sensitive permissions, so start your rollout with administrators rather than finishing with them.
The external user exception. SMS one-time passcodes remain available for external users on customer and partner Experience Cloud sites. That is the only place SMS is a supported option, and it does not extend to your employees.
Practical rollout notes: in orgs created before Summer ’25, an admin has to enable passkey options explicitly, while newer orgs allow all methods by default. Register users before enforcement bites rather than during, and expect step-up prompts on sensitive post-login actions even after a user has authenticated. Microsoft reported in 2019 that MFA can block 99.9% of account compromise attacks, which remains the clearest argument for getting this right.
5. Track User Activity and Monitor for Risks
Each Salesforce monitoring tool answers a different question, and knowing which is which saves a lot of time during an investigation.
- Login History shows who logged in, when, from where, and by which method. Start here for suspected credential problems.
- Login Forensics analyses login patterns to surface anomalies such as unusual locations or repeated failures.
- Setup Audit Trail records configuration changes, including permission and profile edits. This is what tells you who granted an access nobody approved.
- Event Monitoring captures in-app behaviour such as report exports and large data downloads. It is a separate add-on, so confirm your org has it before building a process around it.
The signals worth alerting on are consistent across orgs: repeated failed logins, logins from unexpected geographies, large exports, and permission changes made outside a change window.
6. Automate Onboarding and Access Assignment
Manual provisioning is where access errors originate, because it depends on someone remembering the full list under time pressure.
User Access Policies, generally available since Summer ’24, automate this natively. A policy matches users against criteria such as department or title and then assigns or revokes permission sets, permission set groups, permission set licences, package licences, and membership of public groups and queues. Policies can run automatically when a user is created or updated, or be applied as a one-off to everyone who currently matches. If a user matches several policies, the one with the lowest order value wins, so plan the ordering deliberately.
Login Flows handle the human side of onboarding, prompting first-time users to register an MFA method, accept an acceptable use policy, or complete a short orientation before reaching the app. They are one component of onboarding rather than the whole of it, alongside licence assignment, persona access, training and a manager approval step.
7. Train Users Around Personas and Change
Training sticks when it maps to what someone actually does. Build it by persona rather than delivering one generic session, cover the security behaviours you depend on (recognising phishing, handling exports, why MFA exists), and refresh it when Salesforce releases change the interface three times a year.
Measure something. Login frequency, feature adoption, and the volume of access-related support tickets all indicate whether training landed better than attendance figures do.
How to Audit a User’s Effective Access
Effective access is the sum of everything a user holds through their profile, every permission set, every permission set group, and any muting applied within those groups. Reading each source separately and adding them up by hand is slow and error-prone.
Use the User Access Summary. Open the user record in Setup and click View Summary. Salesforce shows the user’s permissions, object and field permissions, custom permissions, and group and queue membership on a single page, and accounts for muting permission sets when it calculates what is actually enabled. This works for integration and generic users too, which is exactly where excessive permissions tend to hide.
Use it in three situations: when investigating why a user can or cannot do something, during periodic audits to spot-check a persona, and before any role change, so you know what to remove as well as what to add.
A Realistic Lifecycle Example
Consider a sales rep joining, moving to sales operations after a year, then leaving.
Onboarding. A User Access Policy matches her department and assigns the Sales Rep permission set group and the required permission set licence automatically. Her role places her under the regional sales manager, so he sees her pipeline. A Login Flow prompts her to register an authenticator app before she reaches the app for the first time.
Role change. Moving to sales operations, her manager checks the User Access Summary first and finds she still holds a permission set from a project that ended months ago. The old persona group is removed alongside that leftover, and the new one assigned. Her role changes so her visibility follows the new reporting line.
A temporary need. She needs finance report access for a quarter-end project. Rather than a permanent grant, the permission set assignment is given an expiration date that matches the project end, and it lapses without anyone needing to remember.
Offboarding. On her last day she is frozen immediately, which blocks login while preserving the account and its licence for investigation. Her records are transferred, her API tokens revoked, and once the transfers are confirmed she is deactivated, which frees the licence. Freezing and deactivating are different actions for a reason: freezing is instant and reversible, deactivating releases the licence but has to wait until anything that depends on her ownership has been reassigned.
Salesforce User Management Checklist
Onboarding checklist
- Confirm the access request is approved by the hiring manager.
- Assign the correct user licence, and any permission set licence the persona needs.
- Assign the persona permission set group rather than individual permission sets.
- Set the role for record visibility, and confirm it matches the reporting line.
- Set an expiration date on anything temporary.
- Confirm the user registers a supported MFA method at first login.
- Verify the result with the User Access Summary before handing over.
- Record who approved the access and when.
Offboarding checklist
- Freeze the user immediately to block login while preserving the record.
- Revoke API tokens, connected app access and any OAuth sessions.
- Reassign record ownership, open activities and any running automation that references them.
- Remove permission sets, permission set groups and public group membership.
- Check whether they were the sole approver in any approval process and reassign it.
- Deactivate the user to release the licence once transfers are confirmed.
- Record the offboarding in your audit evidence.
Tackling Salesforce Data Risk with Flosum’s Governance Solutions
Access changes are metadata changes, and they deserve the same controls as any other deployment: review before they ship, a record of who approved them, and the ability to roll back. Flosum is an end-to-end enterprise DevSecOps platform purpose-built for Salesforce, so permission sets, profiles and their supporting automation move through version control and approval alongside everything else, with an audit trail that shows what changed and who signed it off.
Its Trust Center adds monitoring and alerting on the org itself, which is the other half of access governance: knowing what changed, not only controlling how it ships. See how Flosum supports risk and governance across your Salesforce environment.
Frequently Asked Questions (FAQ)
Thank you for subscribing
