Not verified hands-on. This article was written from primary documentation rather than reproduced in an org, so it carries no tested-release badge. If you run it and something differs, say so in the comments and it gets tested and corrected.

The quick version: Login As lets an administrator take over another user’s session and see exactly what they see. It needs a Login Access Policies setting plus a user management permission, and the detail that matters is what it leaves behind: records you touch carry the other user’s name, and only the Setup Audit Trail‘s Delegate User column shows someone else was driving. That gap is the whole security argument.

Turning it on

Two routes exist, and they are not the same.

The consent route is on by default. A user grants login access from personal settings for a chosen period, and an administrator gets a Login button on their user record until it expires. The user knows.

The blanket route is the checkbox under Security, Login Access Policies, letting administrators log in as any user without asking. With a user management permission alongside it, that is permanent impersonation across the org. Enabling it deserves a written rationale, not a convenience tick during an escalation.

Whichever route you use, restrict the permission itself. It belongs in a support permission set held by a handful of named people, not in the profile every senior admin inherits.

What is audited, and what is not

This is where expectations and reality part company.

  • Setup changes are attributed correctly. A change made in Setup during an impersonated session appears in the Setup Audit Trail against the impersonated user, with the administrator’s username in the Delegate User column. Read the log without that column and you will reach the wrong conclusion.
  • Record changes are not. Create or edit a record while logged in as someone, and CreatedById and LastModifiedById hold their Id. Field history shows their name. There is no marker on the record saying an administrator did it.
  • Email sends as them. An email sent during the session goes out from the impersonated user, and the recipient has no way to know.
  • Real-Time Event Monitoring captures the session. Orgs with Shield can subscribe to login-as events and store them, which is the only way to monitor this properly at scale.

So you can prove who impersonated whom, provided you look in the right place and pay for the right monitoring. You cannot look at a record and see it.

The security debate

The case against is repudiation. If an administrator can act as a salesperson and the data says the salesperson did it, then every record that salesperson owns is deniable. In regulated environments, auditors ask about this, and “we trust our admins” is not a control.

The case for is that some problems cannot be diagnosed any other way. Sharing, field-level security, record types, layouts and licence-dependent features combine per user, and a screenshot does not tell you which of six permission sets is responsible.

The workable position is a policy rather than a setting. Login As is for looking, not doing. If a change is needed, the administrator makes it as themselves. The session is tied to a ticket reference, and the permission is granted temporarily. That keeps the diagnostic value and removes most of the repudiation problem, because nothing is transacted under the borrowed identity.

What a support person usually actually needs

A surprising share of Login As requests are answerable without it.

“Why can’t they see this record” is answered by the Sharing details on the record, which lists who has access and the reason for it. “Why can’t they see this field” is a field-level security question answerable from the field’s own page. “Why is their layout different” comes down to profile and record type, both visible from the user record.

For how the app behaves rather than what the data shows, a sandbox test user with the same profile and permission sets reproduces the problem with no impersonation and no production risk. Keep one per major profile.

When you genuinely need the real session, a screen share is often faster, and the user sees what you did.

Frequently asked

Does the user know I logged in as them? Not through any notification. If they granted access themselves they know it is possible. Under the blanket policy they have no signal at all.

Can I log in as another administrator? Subject to the same setting and permission, yes, which is worth thinking about when deciding who holds the permission.

How do I get back to my own account? The header shows a link to log out of the impersonated session and return to yours. Use it rather than closing the tab, because leaving an impersonated session open is how the wrong record gets edited.

Does Login As work for Experience Cloud users? Yes, and it is the standard way to diagnose community issues, with the same caveats about attribution applying to anything you touch.