Logged-in User
A logged-in user in Salesforce is the User record that owns the current session.
Definition
A logged-in user in Salesforce is the User record that owns the current session. Every session, whether it runs through the Lightning UI, the REST or SOAP API, a connected app, a flow, or an Apex callout, executes in the context of exactly one user. That user's profile, permission sets, sharing access, role, and locale settings shape what the session can see and do, and the audit trail records the user as the actor behind each change.
The concept sits under almost everything because Salesforce security is user-centric. Record access comes from the logged-in user's sharing. Field-level security comes from the profile and assigned permission sets. Report and folder visibility come from the role hierarchy. Formula functions, Apex methods, and Lightning component imports all expose the logged-in user as a basic piece of session state, so identifying and respecting that user is foundational for any build that needs to be secure, auditable, or personalized.
How the platform reads the logged-in user across every layer
The session always resolves to one User record
When someone authenticates, Salesforce ties the resulting session to a single User record and carries that identity through the request. The same is true for non-interactive sessions. An API client that logs in with a username and password, or with an OAuth flow through a connected app, runs as the user those credentials belong to. A scheduled Apex job runs as the user who scheduled it. A platform event trigger or a flow can run as the Automated Process system user. Because the session resolves to one user, the platform can answer a single question consistently: who is acting right now. That answer drives sharing checks, field-level security, the running context of formulas, and the values written into audit fields. There is no concept of a session with two users at once. Even a "Log in as" support session swaps the running user to the target, while the audit chain still records that an administrator initiated it. Understanding that the session has exactly one owner is the mental model everything else builds on.
The $User global variable in formulas and templates
Formula fields, validation rules, default field values, custom buttons, and email templates read the current user through the $User global variable. The Salesforce help documentation confirms that most fields on the standard User object are also available on $User, so you can reference $User.Id, $User.FirstName, $User.LastName, $User.Username, $User.Email, $User.CompanyName, and $User.IsActive among others. A welcome email template that opens with "Hi {!$User.FirstName}" greets each recipient correctly without any code. A validation rule can compare $User.Id against an owner field to allow only the record owner to change a stage. Related global variables follow the same pattern: $Profile exposes the current user's profile, $UserRole exposes the role, and $Organization exposes company-wide details. Because these merge fields evaluate at run time in the running user's context, they make personalization and lightweight access checks easy without writing Apex. Keep in mind that the value reflects whoever triggered the operation, which on an automated update may be a service account rather than a human.
UserInfo in Apex
Apex exposes the logged-in user through the UserInfo system class. Its methods are static, so you call them directly with no instance. UserInfo.getUserId() returns the current user's 18-character ID, UserInfo.getProfileId() returns the profile ID, and UserInfo.getOrganizationId() returns the org ID. Convenience methods such as getName(), getFirstName(), getLastName(), getUserEmail(), getUserName(), getUserType(), getLocale(), and getDefaultCurrency() cover most context needs without a SOQL query. A common pattern is to stamp a custom field with UserInfo.getUserId() inside a trigger, or to branch logic on UserInfo.getProfileId() so that one profile sees different behavior. Because UserInfo reflects the running user, code that runs in a scheduled job or from an integration login returns that account's values, not a human user's. When you need fields beyond what UserInfo offers, query the User object directly: SELECT Department, ManagerId FROM User WHERE Id = :UserInfo.getUserId(). Treat UserInfo as the fast, query-free door to session context, and fall back to SOQL only for the extra fields it does not surface.
User context in Lightning web components
Lightning web components read the current user with the @salesforce/user scoped module. Per the Lightning Web Components Developer Guide, the module supports two imports: Id and isGuest. You write import userId from '@salesforce/user/Id' to get the user's ID, and import isGuest from '@salesforce/user/isGuest' to learn whether the visitor is an unauthenticated guest on an Experience Cloud site. The isGuest flag is the idiomatic way to branch a component between authenticated and public behavior. The module deliberately does not expose Name, Email, or other profile fields. To read those, import the user ID and pass it to the getRecord wire adapter against the User object, requesting the fields you need such as Name and Email. This split keeps client-side code from assuming sensitive user data is always available. A guest component that tried to read an email it was never granted would simply receive nothing. Designing around Id plus isGuest, then wiring getRecord for the rest, is the supported pattern and keeps your component honest about what data the running user can actually see.
Run As: who the automation acts as
Automation does not always run as the person who clicked. Flows include a "How to Run the Flow" setting whose options are User or System Context. In user context the flow respects the running user's record access and field-level security, which is the safer default. In system context the flow can bypass sharing and, depending on the option, field-level security too, which is sometimes necessary but always widens risk. Apex behaves similarly: a class declared "with sharing" enforces the running user's sharing rules, while "without sharing" ignores them. The point is that the logged-in user defines a context, and several tools let you choose whether to honor that context or step around it. When automation runs in system mode, audit fields still record the actual running user, so the trail does not lie about who triggered the change. Choose user mode unless a genuine requirement forces system mode, and document any system-mode automation so reviewers know access checks were intentionally skipped. Treating Run As as a deliberate decision, rather than an accidental default, is one of the cleaner habits a team can build.
Audit fields trace every change to a user
Salesforce writes system audit fields on nearly every object, and they all point back to a user. The Object Reference lists CreatedById and CreatedDate, set when a record is inserted, plus LastModifiedById and LastModifiedDate, updated on every change. These fields are read-only in normal use and populate automatically from the running user, which is what makes the audit chain trustworthy. When an integration writes records, CreatedById holds the integration account's ID, not a human's, so security and reporting reviews should account for service accounts when they read these fields. The same logic applies to scheduled jobs and platform-event automation that run as the Automated Process user. Pairing these record-level fields with org-level tools such as the Setup Audit Trail, and with Real-Time Event Monitoring for login and session events, gives a fairly complete picture of who did what and when. If you ever debug a record that changed unexpectedly, LastModifiedById is usually the first field to check, and it points straight at the logged-in user behind the edit.
Humans, integration users, and Log in as
Not every logged-in user is a person at a keyboard. Integrations often authenticate as a dedicated account, sometimes an Integration User license created for API-only access. For the life of that API session, the integration account is the logged-in user, and every record it touches traces to it. Keeping these accounts separate from human users is what lets a security analyst tell automated traffic apart from real activity in audit reports. On the support side, administrators with the right permission can use "Log in as" to start a session as another user and reproduce an issue from that person's exact context. During that session the platform treats the target as the logged-in user for sharing and visibility, while the audit chain still records that an admin initiated the impersonation. Because impersonation can be confusing after the fact, documenting when and why it was used in an admin runbook saves time later. The broad lesson is to always ask which user a session belongs to, since the answer changes access, behavior, and the story the audit trail tells.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Logged-in User.
Hands-on resources to go deeper on Logged-in User.
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. Which Apex system class exposes the Logged-In User's ID, profile, and org ID without a SOQL query?
Q2. In a record-triggered Flow, what does the default Run As setting of User Who Launched the Flow mean for the logged-in user?
Q3. Which two fields does Salesforce auto-populate from the logged-in user every time a record is inserted?
Discussion
Loading discussion…