Access patterns differ by surface: formulas, Apex, Lightning, flow. Pick the right pattern per the use case.
- In formulas, use $User merge fields
$User.Id, $User.FirstName, $User.Email, etc. Drop them into formula fields, validation rules, email templates, Visualforce.
- In Apex, use UserInfo
Id myId = UserInfo.getUserId(); String myProfile = UserInfo.getProfileId(); No instantiation needed.
- In Lightning Web Components, import from @salesforce/user
import userId from ''@salesforce/user/Id''; The component receives the value statically at render time.
- In Flow, use $User global variable
{!$User.Id}, {!$User.FirstName}, etc., in any flow formula or merge field.
- For impersonation testing
Setup, Users, click Login next to the user. Salesforce switches the session to that user for testing. Use sparingly; document the impersonation.
- For audit reporting
Query CreatedById and LastModifiedById on the relevant object. Group by user to surface activity patterns.
Every session has a logged-in user; access patterns differ by surface.
Decide what the logged-in user can do.
Audit fields populated automatically.
Decides whether automation respects the logged-in user.
- System Mode flows bypass the logged-in user''s sharing. Use only when absolutely required.
- Integration users are the logged-in user for the API session. Audit reports must distinguish them from real users.
- Impersonation (Login As) changes the logged-in user temporarily. Audit fields still track the impersonating user; document the use.
- The $User global in formulas evaluates at render time, not at record save. Use $User in display contexts; use UserInfo in code logic.