Users are at the center of everything in Salesforce. Every record has an owner. Every action has an actor. Every permission, every automation, every report — it all ties back to users. Getting user management right is one of the most important things a Salesforce Admin does.
In this section, we’ll cover the complete lifecycle of a Salesforce user — from creation to daily management — and the license mechanics that determine what each user can actually do.
What Are Users in Salesforce?
A user in Salesforce is anyone who has login credentials to access your org. Every user has a User record — a standard Salesforce object that stores their name, email, profile, role, license type, time zone, and dozens of other settings.
Users aren’t just your employees. Depending on your org’s setup, users can include:
- Internal users — Employees who use Salesforce as part of their daily work (sales reps, support agents, admins, developers)
- External users — Customers, partners, or vendors who access your org through an Experience Cloud site (portal)
- Integration users — Dedicated users that represent external systems connecting to Salesforce via API
- System users — Automated process users like the “Automated Process” user that runs Flows, or the “Platform Integration” user
The User Record
Every user record contains key fields that control their experience:
| Field | Purpose |
|---|---|
| Username | Unique identifier across ALL Salesforce orgs (not just yours). Must be in email format but doesn’t need to be a real email. |
| The actual email address for password resets, notifications, and email-to-case | |
| Profile | Determines baseline permissions — what objects, fields, and features the user can access |
| Role | Determines the user’s position in the role hierarchy, which affects record visibility |
| User License | The license type assigned, which determines what Profile options are available |
| Active | A checkbox that controls whether the user can log in. Deactivating a user frees up the license. |
| Time Zone | The user’s local time zone for displaying datetime values |
| Locale | Controls date/number formatting for this user |
| Language | The language of the Salesforce UI for this user |
Critical detail about Usernames: A username must be globally unique across every Salesforce org in existence — not just your org. This is why many companies use the format firstname.lastname@company.com.orgname. If someone at another company already has john@company.com as a username, you can’t use it. The username doesn’t need to match the user’s actual email, and it often shouldn’t (especially in sandboxes).
The Permissions Needed to Create and Manage Users
Before you can create or manage users, your own user account needs the right permissions. Here’s what’s required:
Minimum Permissions for User Management
| Permission | What It Allows |
|---|---|
| Manage Users | Create, edit, and deactivate users. This is the primary permission. |
| Manage Internal Users | Similar to Manage Users but scoped to internal users only |
| Manage External Users | Create and manage Experience Cloud (portal/community) users |
| Reset User Passwords and Unlock Users | Reset passwords and unlock accounts without full Manage Users access |
| Manage Profiles and Permission Sets | Required if you need to create or modify profiles/permission sets while managing users |
| Manage Roles | Required to assign or change a user’s role in the hierarchy |
| Assign Permission Sets | Assign permission sets to users (can be granted separately from Manage Users) |
How to Check Your Own Permissions
- Go to Setup → Users and find your own user record
- Click on your Profile name to see what permissions it grants
- Check any Permission Sets assigned to you for additional permissions
Delegated Administration
If you need someone to manage users without giving them full admin access, Salesforce supports Delegated Administration (covered in detail in a later section). This lets you designate specific users who can create and manage users within defined constraints — specific roles, specific profiles, etc.
Best practice: Don’t give every admin the “Manage Users” permission on their profile. Instead, use a Permission Set called something like “User Management” and assign it only to those who need it. This follows the principle of least privilege and makes it easy to audit who can manage users.
How to Create a User
Step-by-Step: Creating a Single User
- Navigate to Setup → Users → Users (Quick Find: “Users”)
- Click “New User”
- Fill in the required fields:
Required fields:
- Last Name — The user’s surname
- Alias — Auto-generated from the name, used in list views and reports (max 8 characters)
- Email — Where notifications, password resets, and alerts are sent
- Username — Must be globally unique and in email format
- Nickname — Used in Chatter and community feeds
- Role — Optional but highly recommended (affects record access)
- User License — Determines what the user can access (we’ll deep-dive into this below)
- Profile — Determines baseline permissions. Available profiles depend on the selected license.
- Set optional fields:
- Time Zone, Locale, Language — Defaults from org settings but can be overridden per user
- Manager — Links to another user record. Used in approval processes and some hierarchy features.
- Title, Department, Division — Informational fields useful for reporting
- Generate new password and notify user immediately — Check this to auto-send login credentials
- Click “Save”
The user will receive an email with their username and a link to set their password (if you checked the notification option).
Adding Multiple Users at Once
For bulk user creation:
- Setup → Users → Users
- Click “Add Multiple Users”
- Select the User License and Profile (all users in this batch will share the same license and profile)
- Enter up to 10 users at a time with their name, email, and username
- Click “Save”
For larger batches (50+ users), use the Data Loader or Salesforce CLI to import users from a CSV file. The User object is fully accessible via API.
Common Mistakes When Creating Users
-
Using a real email as the username — This works but causes confusion in sandboxes. When a sandbox is created, Salesforce appends the sandbox name to usernames (e.g.,
john@company.com.dev), but the email field stays the same. Use a consistent naming convention. -
Forgetting to assign a Role — Users without a role are essentially invisible in the role hierarchy. This affects sharing and record visibility. Always assign a role unless you have a specific reason not to.
-
Selecting the wrong license type — Changing a user’s license type after creation is possible but can break things. If a user had access to Opportunities (full CRM license) and you switch them to a Platform license, they lose access to Opportunities and any related configurations.
-
Not setting Manager field — The Manager field is used by approval processes, delegated admin features, and some reporting. Set it during creation so you don’t have to backfill later.
How to Reset a User’s Password
This is probably the most common support request you’ll get as an admin. Here are the methods:
Method 1: Admin Reset (from Setup)
- Setup → Users → Users
- Find the user and click their name
- Click “Reset Password” button
- The user receives an email with a link to create a new password
Note: This generates a temporary link that expires after 24 hours. If the user doesn’t reset within that window, you’ll need to send it again.
Method 2: Admin Reset (from the User list)
- Setup → Users → Users
- Click “Reset Password” next to the user in the list view (no need to open the record)
Method 3: User Self-Service
Users can reset their own password from the login page:
- Go to the Salesforce login page
- Click “Forgot Your Password?”
- Enter their username
- They receive an email with a reset link
This only works if:
- The user knows their username
- Their email address in Salesforce is correct and accessible
- The org hasn’t disabled self-service password resets (check: Setup → Password Policies)
Method 4: API / Salesforce CLI
For automated or bulk password resets:
sf data update record --sobject User --where "Username='john@company.com'" --values "Password='TempPass123!'"
Or use the setPassword() method in Apex for programmatic resets.
Unlocking a Locked Account
If a user fails too many login attempts, their account gets locked (based on your org’s password policies). To unlock:
- Setup → Users → Users
- Find the locked user
- Click their name
- Check the “Unlock” checkbox (appears only when the account is locked)
- Click “Save”
Alternatively, the lockout expires automatically after the duration set in your password policies (default: 15 minutes).
Password Policy Configuration
You can configure password requirements at: Setup → Password Policies (Quick Find: “Password Policies”)
Key settings:
- Minimum password length (recommend 10+)
- Password complexity (require uppercase, lowercase, numbers, special characters)
- Password expiration (how often users must change passwords — though MFA is more important than rotation)
- Maximum login attempts (before lockout)
- Lockout duration (how long before auto-unlock)
- Obscure secret answer (for security questions — keep this ON)
How to Check if a User Successfully Logged In
Verifying user logins is essential for security audits, troubleshooting, and compliance. Salesforce provides several ways to track this.
Method 1: Login History (User Record)
- Setup → Users → Users
- Click the user’s name
- Scroll down to the “Login History” related list
- You’ll see their recent logins with timestamp, source IP, login type, and status
This shows the last 6 months of login history for that specific user.
Method 2: Org-Wide Login History
For a broader view across all users:
- Setup → Login History (Quick Find: “Login History”)
- This shows login attempts across the entire org
- You can filter by date range, username, login type, and status
- Download as CSV for analysis
Key columns to review:
- Status — “Success” or the specific failure reason (Invalid Password, Locked Out, etc.)
- Source IP — Where the login came from. Unexpected IPs may indicate compromised credentials.
- Login Type — How they logged in (UI, API, SAML SSO, OAuth, etc.)
- Application — Which connected app or method was used
- Browser — The browser and version used for UI logins
Method 3: Setup Audit Trail
The Setup Audit Trail tracks admin configuration changes, not logins. But it’s useful for monitoring:
Setup → View Setup Audit Trail (Quick Find: “Audit Trail”)
This shows the last 6 months of setup changes — who changed what, when. Essential for tracking unauthorized configuration changes.
Method 4: Login Forensics (Shield Add-On)
If your org has Salesforce Shield (an add-on product), you get:
- Login Forensics — Detailed login analytics including anomaly detection
- Event Monitoring — Granular tracking of user actions (page views, report exports, API calls)
- Transaction Security — Real-time policies that can block or alert on suspicious activity
Shield is expensive but necessary for orgs with strict compliance requirements.
Practical Monitoring Tips
-
Check login history when a user reports issues — “I can’t log in” often means “I’m using the wrong username” or “I’m logging into the wrong environment.” Login History reveals the truth.
-
Monitor API login volume — A sudden spike in API logins from an integration user could indicate a runaway process or a compromised API key.
-
Watch for logins from unexpected locations — If your company is India-based and you see successful logins from an unfamiliar country, investigate immediately.
-
Review failed login attempts — Multiple failures followed by a success could indicate a brute-force attack.
How to Proxy Login as a User in Salesforce
Proxy login (also called “Login As”) lets an admin log in as another user to see exactly what they see. This is invaluable for troubleshooting — when a user says “I can’t see this record” or “this page looks broken,” you can experience their exact view.
How to Enable It
Login As is controlled at two levels:
Org-Level Setting:
- Setup → Login Access Policies (Quick Find: “Login Access Policies”)
- Check “Administrators Can Log in as Any User”
User-Level Setting (optional): Individual users can grant login access to admins for a defined period:
- The user goes to Settings → Grant Account Login Access
- They select the support team or admin and set a duration
How to Log In as Another User
- Setup → Users → Users
- Find the user
- Click “Login” next to their name in the list view
You’ll be logged in as that user in a new session. You’ll see their home page, their permissions, their record access — everything exactly as they experience it.
A yellow banner appears at the top of the page reminding you that you’re logged in as another user. To return to your own account, click “Log out” or close the session.
What Happens During a Login As Session
- You see everything the user sees — including records they have access to and pages configured for their profile
- Your actions are logged as the user in most contexts, but the Login History shows it was a “Login As” event
- You cannot do certain things: you can’t change the user’s password, and some security-sensitive operations are blocked
- The session respects the user’s profile and permission set assignments, not yours
When to Use Proxy Login
| Scenario | Use Login As? |
|---|---|
| User says they can’t see a field | Yes — verify their field-level security |
| User reports a page layout issue | Yes — see their exact page layout |
| User says a Flow isn’t working | Yes — trigger the Flow as them |
| Debugging a permission issue | Yes — fastest way to verify access |
| Making configuration changes | No — always make changes as yourself |
| Testing a new feature before rollout | Yes — test as a user with the target profile |
Security Considerations
- Audit logging — Every Login As session is tracked. Admins can’t log in as users invisibly.
- Compliance — Some regulated industries prohibit Login As because it bypasses the user’s own authentication. Check your compliance requirements.
- Trust — Users should know that admins can log in as them. Transparency builds trust. Never use Login As to snoop on users or read their private Chatter messages without a legitimate business reason.
- Disable when not needed — If your org’s security policy requires it, disable the “Administrators Can Log in as Any User” setting and rely on the user-granted access approach instead.
User License Assignments and How They Impact Your Users
This is where user management gets expensive — and where understanding the nuances can save your company significant money.
What is a User License?
A User License is a purchased entitlement that determines the baseline capabilities a user has in Salesforce. The license type controls:
- Which profiles can be assigned to the user
- Which standard objects the user can access
- Which features the user can use
- The cost per user per month
Think of it like a theme park ticket: the license determines which sections of the park you can enter. Profiles and permission sets then fine-tune what you can do within those sections.
Core License Types in Detail
Salesforce License (Full CRM)
What it includes:
- Full access to all standard CRM objects: Accounts, Contacts, Opportunities, Cases, Leads, Campaigns, etc.
- Access to custom objects
- Full Flow and automation capabilities
- API access (Enterprise Edition and above)
- All standard Lightning features
Who needs it:
- Sales representatives (need Opportunities, Leads)
- Account managers (need Accounts, Contacts, Opportunities)
- Service agents (need Cases) — though Service Cloud has its own consideration
- Anyone who needs the full CRM feature set
Cost: The most expensive per-user license. Pricing varies by edition and negotiation, but expect $150-$330/user/month at list price for Enterprise Edition.
Salesforce Platform License
What it includes:
- Access to custom objects and custom apps only
- Access to Accounts and Contacts (read/create/edit — these are considered “base” objects)
- Chatter, Reports, Dashboards, and Content
- Flow automation
- API access
What it does NOT include:
- Opportunities, Leads, Campaigns, Forecasting
- Cases, Solutions, Entitlements
- Any Sales Cloud or Service Cloud-specific features
Who needs it:
- Users who only interact with custom applications built on the Salesforce platform
- Operations teams using a custom time-tracking or inventory app
- HR teams using a custom onboarding workflow
- Anyone who doesn’t need standard CRM objects
Cost: Significantly cheaper — roughly 60-70% less than a full Salesforce license.
This is where the money-saving opportunity is. In many orgs, 20-40% of users only interact with custom objects and never touch Opportunities or Cases. Switching them to Platform licenses can save tens of thousands of dollars annually.
Identity License
What it includes:
- Single Sign-On (SSO) authentication through Salesforce
- No access to the Salesforce platform, objects, or data
Who needs it:
- Users who need Salesforce as their identity provider for other apps
- SSO-only scenarios
Cost: Very cheap — minimal per-user cost.
Community/Experience Cloud Licenses
There are multiple tiers:
Customer Community:
- Basic portal access for customers
- Limited to custom objects and a subset of standard objects
- No access to Opportunities, standard reporting, or API
- Cheapest external user license
Customer Community Plus:
- Everything in Customer Community
- Plus sharing rules, roles, delegated admin
- Access to reports and dashboards
- More expensive than Customer Community
Partner Community:
- Everything in Customer Community Plus
- Plus access to Opportunities, Leads, Campaigns (for partner sales)
- Most expensive community license
Pricing models:
- Per-member — Fixed cost per user per month (regardless of how often they log in)
- Per-login — Pay per login. Cheaper per-login but adds up for frequent users.
Decision framework:
- External users who log in daily → Per-member
- External users who log in a few times a month → Per-login
- Calculate the break-even: if per-login cost × average monthly logins > per-member cost, switch to per-member
Chatter Free / Chatter External
Chatter Free:
- Free license for internal users who only need Chatter (Salesforce’s collaboration tool)
- Can post, comment, share files, join groups
- No access to any Salesforce data or objects
Chatter External:
- Free license for external users who only need Chatter collaboration
- Can be invited to specific Chatter groups
- No access to any Salesforce data
Who needs it: Employees who need to collaborate in Chatter but don’t need CRM access. Common for executives who want to see updates without a full license.
License Assignment Best Practices
-
Audit annually — Review whether each user has the right license type. People change roles. A user who needed a full CRM license a year ago might only need Platform now.
-
Map licenses to personas — Before buying, define user personas and map them to license types:
- “Sales Rep” → Salesforce License
- “Warehouse Manager” → Platform License
- “Customer” → Customer Community (per-login)
- “Partner Sales” → Partner Community (per-member)
-
Deactivate, don’t delete — When someone leaves the company, deactivate their user (uncheck the Active checkbox). Never delete a user record — doing so orphans their data and breaks audit trails. Deactivating frees the license for reassignment.
-
Monitor license usage — Setup → Company Information shows total licenses vs. used. If you have 100 Salesforce licenses and only 70 are active, you’re overpaying for 30 unused licenses. Negotiate down at renewal.
-
Use Permission Set Licenses — Some features require additional Permission Set Licenses (e.g., Sales Cloud Einstein, Service Cloud Einstein, CRM Analytics). These are assigned separately from the user license and can be added to specific users without upgrading everyone.
How to Change a User’s License
- Setup → Users → Users
- Click the user’s name → Edit
- Change the User License field
- The Profile dropdown will update to show only profiles compatible with the new license
- Select a compatible profile
- Save
Warning: Changing a license type can remove access to objects and features the user was previously using. Any automations, reports, or dashboards owned by that user that reference now-inaccessible objects will break. Always audit before switching.
Section Notes
Key takeaways from this section:
- Usernames are globally unique — across all Salesforce orgs, not just yours. Establish a naming convention early.
- Always assign a Role — Users without roles have limited visibility in the sharing model. This is the #1 overlooked step when creating users.
- Deactivate, never delete — When employees leave, deactivate their user. Deletion orphans data.
- License type = cost control — The biggest Salesforce cost-saving lever is ensuring users have the right (and cheapest appropriate) license type. Audit this regularly.
- Login As is your superpower — When troubleshooting, don’t guess what the user sees. Log in as them and see it yourself.
- Login History is your evidence — When something goes wrong, Login History and Setup Audit Trail are the first places to check.
- Password policies + MFA — Configure both. MFA is now required by Salesforce. Password policies are your backup layer.
This is Part 3 of the Salesforce series. Next up: Objects and Fields — the data model that everything in Salesforce is built on. We’ll cover standard vs. custom objects, field types, relationships, schema builder, and field history tracking.