2.2 User Records, Licenses, Profiles, Permission Sets, and Login Access

User records as access contracts

A Salesforce user record is more than a name and email address. It ties a person to a username, user license, profile, role, permission set assignments, locale, time zone, manager, delegated administration, default currency when applicable, and feature-specific settings. In Setup, the core path is Setup > Users > Users. From there, an admin can create users, freeze users, reset passwords, assign permission sets, inspect login history, and manage login access policies depending on org configuration.

The first judgment point is the user license. A license controls which platform features and object families are available at all. If a user has a license that does not support a feature, assigning a permission set cannot magically grant it. This matters in scenarios involving Salesforce Platform users, Experience Cloud users, add-on feature licenses, permission set licenses, and Agentforce-related capabilities. Before troubleshooting object permissions, confirm that the license can support the requested work.

Profiles still matter because every user has exactly one profile. The profile provides a baseline for object permissions, field permissions, tab visibility, app access, login hours, login IP ranges, page layout assignment, record type access, and system permissions depending on configuration. However, a profile should not become a custom snowflake for every small job variation. Too many profiles make audits painful and increase the chance that a future admin grants broad access just to fix one edge case.

Permission sets are the cleaner tool for incremental access. If a sales operations analyst needs report export ability for a project, a permission set can grant the specific permission without changing every user on the profile. Permission set groups help bundle related permissions for a job function, and muting permissions can suppress permissions inside a group where supported. Permission set licenses may also be required before some permissions become assignable. The exam trap is choosing a profile clone when a permission set would solve a narrow access requirement with less risk.

Access layering model

Roles are frequently confused with profiles. A profile answers what the user can do. A role helps determine which records the user can see through the role hierarchy and sharing model. In a small org, some users may have no role, but in a sales or service hierarchy the role is often essential for manager visibility, forecasts, and territory-adjacent reporting. If a manager can run the app but cannot see subordinate records, the profile may be fine while the role or sharing model is wrong.

Usernames are globally unique across Salesforce, while emails are not the same thing as usernames. In sandbox and Developer Edition practice, this can surprise new admins who try to reuse an email-style username. A common pattern is to use a unique username that looks like an email address but includes an environment marker. The user email controls notifications and password reset delivery, so it still must be accurate for real users.

Deactivation is another scenario-heavy area. Salesforce users are usually not deleted because they own records, appear in history, and are part of audit trails. Deactivation prevents login and frees many user licenses, but it can require reassignment of ownership, scheduled jobs, queues, workflow users, default lead owners, and integration ownership. Freezing a user prevents login quickly but does not replace deactivation or reclaim the license. Use freezing when immediate login prevention is needed while you prepare the full deactivation checklist.

Login access grants are for support and troubleshooting, not a workaround for permissions. A user may grant an admin or Salesforce support temporary access to inspect behavior as that user, depending on org settings. Admins should use this capability with a clear reason, limited duration, and audit awareness. If the goal is to let another employee do the work permanently, assign the correct permission set or transfer ownership instead.

Hands-on practice should include creating a limited test user in a Trailhead Playground or Developer Edition org. Assign a standard profile, then create a small permission set that grants access to a custom object or report capability. Log in as the user if allowed, or use permission inspection tools where available, and verify what changed. Then remove the permission set and verify the capability disappears. This teaches the difference between the baseline and the exception.

Onboarding workflow

1. Confirm the worker type, department, manager, region, and job tasks.
2. Choose the correct user license and any required permission set licenses.
3. Assign the baseline profile and role based on job family and visibility needs.
4. Add permission sets or permission set groups for additional duties.
5. Set locale, language, time zone, default currency if relevant, and email settings.
6. Validate login, app access, object access, record visibility, and critical reports.
7. Document the access pattern so the next similar user can be onboarded consistently.

The safest admin habit is to solve the smallest true problem. If the user cannot open an object tab, check app navigation, tab visibility, object permission, and license. If the user can open the object but cannot see records, inspect role, sharing rules, teams, territories, queues, or ownership. If the user can see the record but cannot edit a field, inspect field-level security, page layout, record type, validation rules, and automation. User management questions reward that diagnostic sequence.