Users
A User in Salesforce is a record that represents one person (or, in some cases, a system or integration identity) who can log in to the org.
Definition
A User in Salesforce is a record that represents one person (or, in some cases, a system or integration identity) who can log in to the org. Each User record holds the login credentials, the assigned license and profile, and the settings that decide what that person can see and do. The Users page in Setup is where administrators view every User record and create, edit, freeze, deactivate, or reset passwords for those accounts.
Every action taken in Salesforce traces back to a User. Record ownership, audit fields like Created By and Last Modified By, sharing, and login history all hang off the User record. That makes Users the anchor of both day-to-day access and long-term governance, which is why most admin security work starts here.
How the User record anchors access and accountability
Where Users lives and who can open it
You reach Users from Setup by typing Users in the Quick Find box and selecting Users. The page lists every account in the org with sortable columns for full name, alias, username, role, profile, active status, and the assigned user license. From the list you can open a single record, edit several rows inline, reset passwords for selected users, unlock locked-out accounts, and freeze or deactivate people. Two permissions gate this work. To see the list at all, a user needs View Setup and Configuration. To actually create or change accounts, they need the Manage Users permission. Manage Users is powerful, so it usually sits with a small admin team rather than every power user. The maximum number of accounts you can hold depends on your Salesforce edition and the licenses you have bought. When Enhanced User List View is enabled, the page adds search and richer filtering, which helps a lot once an org grows past a few hundred people and scanning the raw list stops being practical.
The fields that define an identity
A User record carries the data that makes a person both reachable and constrained. Name and Email are the human-facing parts. Alias is a short label that appears in lists where space is tight. Nickname identifies the person in community and Chatter contexts. The Username is the real login identity, and it must be unique across every Salesforce org on the planet, including sandboxes and trials. Username has to be formatted like an email address, but it does not have to be a working mailbox, which is why teams often use values like jane@company.com.prod or jane@company.sandbox. Two more fields do the heavy lifting on access. The User License sets the broad category of what the account can reach, such as Salesforce or Salesforce Platform. The Profile, which must be compatible with that license, then defines the baseline of object access, field access, and system permissions. Role is optional and feeds the role hierarchy for record visibility. Together these fields turn a name into a governed identity.
Creating a user and the first login
Adding someone is a single-record create. You click New User, fill in name and email, set a username, pick a license, and choose a compatible profile. If approvals are enabled you can also set an approver. The option Generate new password and notify user immediately emails the new person a verification link so they can set their own password on first login. That link is time limited. If it expires, or if the person clicks through but never finishes setting a password, an admin has to reset the password before the account works. For onboarding many people at once, Add Multiple Users lets you create up to ten records on one screen, and Data Loader or the API handle larger waves. One detail trips up new admins. Salesforce Customer Support cannot rename a username or deactivate an account for you. That makes the username choice and the activation flow something your own team owns end to end, so it is worth getting the naming convention right before the first batch goes in.
Freeze versus deactivate
When access has to stop, you have two levers, and they are not interchangeable. Freezing an account blocks login immediately while leaving everything else in place. It is the right move when you need to cut access fast but still have cleanup to finish, or when the account is a system identity that cannot be deactivated at all. The key limit is that freezing does not return the user license to your pool. The seat stays consumed. Deactivation is the permanent step. A deactivated user cannot log in, and the license is released back so you can assign it to someone else. Deactivation is also the only path that frees a paid seat, so license recovery always means deactivate, not freeze. Certain accounts, such as the Automated Process user and some integration or portal admin identities, cannot be deactivated, which is exactly where freeze earns its place. A common pattern is to freeze the moment someone leaves, reassign their open work, then deactivate once the record is clean.
What deactivation leaves behind
Deactivation does not erase a person from your data. A deactivated user keeps ownership of the records they owned, and their name stays visible in Created By, Last Modified By, and other history. That is by design, because rewriting audit trails would destroy accountability. The catch is that orphaned ownership can hide work. Open cases, leads, and opportunities owned by an inactive person can fall out of most reports and queues, so reassign that pipeline before you flip the switch, not after. Other ties need attention too. The person cannot be the only recipient of a workflow email alert, and they should be removed from account and opportunity teams. Dashboards and scheduled jobs they own may need a new running user, and territory assignments drop off automatically under Enterprise Territory Management. There is also a scale warning. If the account owns or shares a very large volume of records, transfer that ownership in bulk first, because deactivating a heavy owner without prep can slow the org while sharing recalculates.
Users as the hub of your security model
The User record is where Salesforce permissions and sharing converge. Profile and permission sets decide what a person can do. Role and the role hierarchy, plus sharing rules and groups, decide which records they can see. Login history, password policies, and any single sign-on or multi-factor settings all attach to the same record. Because so much hangs off one object, hygiene here pays off everywhere else. Stale active accounts are both a security gap and a wasted spend, since a license you pay for but nobody uses is money lost. A simple discipline catches most of this. Review login history on a schedule and flag any active user who has not signed in for ninety days. Either they should have been deactivated, or they are a seat you can reclaim. Treating Users as a living governance surface, rather than a list you only touch at onboarding, keeps access tight and the license count honest as the org grows.
How to add a single user
Add one person to your org from Setup. You need the Manage Users permission and a free seat of the right license. Have the person's name, email, and your team's username convention ready before you start.
- Open the Users page
From Setup, type Users in the Quick Find box and select Users. Click New User to open a blank User record.
- Enter identity and contact details
Fill in the first and last name, email, alias, and nickname. Set the Username in email format, and make sure it is unique across every org, including sandboxes.
- Assign license, profile, and role
Pick a User License from your available seats, then choose a Profile that is compatible with it. Set a Role if you want the account in the role hierarchy.
- Send credentials and save
Select Generate new password and notify user immediately so the person gets a verification email. Click Save. If the link expires before they finish, reset the password for them.
The person's surname and a working email address that receives the activation message.
The login identity in email format, unique across all Salesforce orgs. It does not have to be a real mailbox.
A short label shown in list views where the full name will not fit. Salesforce suggests one automatically.
The seat type that sets the broad scope of access and must match the profile you choose.
The permission baseline for object, field, and system access. It has to be compatible with the selected license.
- Salesforce Support cannot rename a username or deactivate a user for you, so own your naming convention from day one.
- The activation email link is time limited. If it expires, an admin must reset the password before the account can log in.
- The profile list is filtered by the license you pick, so choose the license first or the profile you want may not appear.
Trust & references
Cross-checked against the following references.
- View and Manage UsersSalesforce
- Considerations for Deactivating UsersSalesforce
Straight from the source - Salesforce's reference material on Users.
- Add a Single UserSalesforce
- Freeze or Unfreeze User AccountsSalesforce
Hands-on resources to go deeper on Users.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. Can a Salesforce admin configure Users without writing code?
Q2. In which area of Salesforce would you typically find Users?
Q3. What is the primary benefit of Users for Salesforce administrators?
Discussion
Loading discussion…