Login Access Policies
Login Access Policies is the Setup page in Salesforce where an administrator controls who can log in as another user and which packaged publishers users are allowed to grant login access to.
Definition
Login Access Policies is the Setup page in Salesforce where an administrator controls who can log in as another user and which packaged publishers users are allowed to grant login access to. It governs the privacy default for impersonation: whether an admin must wait for a user to grant access before using Login As, or whether admins can log in as any user without that consent. The page lives under Setup in the Quick Find box as "Login Access Policies."
The page exposes one global toggle, "Administrators Can Log in as Any User," plus a row for every managed package publisher that supports login access. For each publisher you decide whether both users and admins can grant access, or only admins can. The feature is consent-based by default. Even a System Administrator with Modify All Data cannot impersonate someone until that person grants access from their own Personal Settings, and every login-as session is recorded in the Setup Audit Trail.
How the impersonation policy is wired
The consent default and Grant Account Login Access
Out of the box, no admin can log in as a user without that user's permission. The user opens their profile menu, picks Settings, types "Grant" in the Quick Find box, and opens Grant Account Login Access. There they choose a value from the Access Duration picklist, up to a maximum of one year, and save. The clock starts the moment access is granted. If a user grants one day, the admin loses access exactly 24 hours later. During the window, an admin with the right permission can use Login As from the user's detail record to see exactly what that user sees and reproduce a problem. This consent model is the platform's privacy floor. It prevents surprise impersonation and gives the user a record of who they let in and for how long. The same Grant Account Login Access flow is how a user lets a Salesforce Support engineer into their account for a case. One important rule: a user can only grant access to their company's admins and to Salesforce Support, never to other ordinary users. An admin cannot grant Support access on an end user's behalf either, so the user has to do it themselves.
Administrators Can Log in as Any User
The single most consequential setting on this page is the "Administrators Can Log in as Any User" checkbox. Turn it on and admins holding Modify All Data and Manage Users can log in as any active user without waiting for a grant. Turn it off and the consent model above is back in force. The setting is off by default and is available in Enterprise, Performance, Unlimited, and Developer editions, not Professional or lower. The trade-off is speed against privacy. Support-heavy operations enable it so an admin can jump into a user's session the moment a ticket lands. Privacy-conscious and regulated orgs leave it off so impersonation always carries an explicit, time-boxed user grant. A few mechanics matter in practice. You cannot start a login-as session while you are already logged in as someone else. You cannot impersonate inactive users. And when an admin logs out after a login-as session, their own session ends too, so they sign back in. Even with this setting on, Salesforce Support still cannot ride an admin's login to reach other users; Support access is always granted per user.
Per-publisher grant controls
Below the global toggle, the page lists every managed package publisher in your org that supports login access. Each row carries its own access choice. "Available to Administrators and Users" lets both end users and admins grant that publisher's support team login access to an account. "Available to Administrators Only" restricts the grant to admins who hold Manage Users, so individual end users cannot expose their session to that publisher. This row-by-row control is how you let a trusted ISV's support engineers troubleshoot inside your org while keeping a different package locked down. A couple of caveats show up here. Packages that are licensed to the whole org, rather than to individual users, can only be managed by admins, so user-level grants do not apply. And some packages do not implement login access at all, so they never appear in the list. When a vendor asks you to grant their engineer access for a case, this is the page that decides whether that grant is even possible and who is allowed to make it.
Login As behavior in the running session
When an admin starts Login As, the platform makes the impersonation visible. The admin sees the target user's pages, permissions, and record visibility, with a clear indication in the interface that they are operating as that user. This is the point of the feature: to reproduce a bug or confirm a configuration from the exact vantage point of the person reporting it, instead of guessing from the admin's own broader access. Actions taken during the session are recorded so the org can tell impersonated activity apart from the user's own work. The login-as context also has edges worth knowing. OAuth and Connected App flows can behave differently under impersonation because the authentication context is not the user's real login, so some integration paths cannot be fully tested this way. High-assurance session requirements can also complicate things when the user needs a stronger session than the admin currently holds. Plan for cases where Login As gets you most of the way but a true end-to-end test still needs the user's own authenticated session.
Auditing every login-as event
Every login-as event lands in the Setup Audit Trail, the org's running log of administrative changes. The entry captures who logged in as whom and when, which is the evidence compliance teams look for whenever impersonation is enabled. Treat that trail as a monitoring source, not just an archive. Export it or feed it into a SIEM and alert on patterns that should be rare: an admin logging in as a senior executive, repeated login-as sessions targeting the same user, or impersonation outside business hours. Because the running session shows the admin is impersonating, and the activity is recorded, you get both a real-time signal and an after-the-fact record. The Setup Audit Trail also captures the changes a Support engineer makes while inside a granted account, which is why granting Support access through the consent flow still leaves a reviewable trail. For regulated orgs, the combination of consent grants, visible sessions, and audit entries is usually what satisfies an auditor that impersonation is controlled rather than open-ended.
Putting a real policy around it
The settings are only half the job; the operating procedure around them is the other half. Decide as a team whether "Administrators Can Log in as Any User" should be on at all, and write down the reasoning so a future audit can see it. If you keep it off, standardize the grant duration you ask users for so support requests do not turn into open-ended year-long windows by default. If you turn it on, restrict Modify All Data and Manage Users to a small, named group, because those two permissions are what make login-as possible. Train support staff to confirm with the user before impersonating, even when a grant is already in place, and to record each login-as session in the relevant ticket with what they did and why. Review the Setup Audit Trail on a schedule rather than only after an incident. None of this lives on the Login Access Policies page itself, but the page is where the technical guardrails are set, and the written policy is what keeps a powerful capability from drifting into something nobody can account for later.
Configuring Login Access Policies
Login Access Policies is reached from Setup and controls both the global login-as toggle and per-publisher grant permissions. Configure it deliberately, because the global setting changes whether impersonation needs user consent at all.
- Open the page
In Setup, type "Login Access Policies" in the Quick Find box and select Login Access Policies. You need an admin profile with the Customize Application and user-management permissions to see and change it.
- Decide on the global toggle
Set the "Administrators Can Log in as Any User" checkbox based on your privacy stance. Checked lets qualified admins impersonate without a grant; unchecked keeps the consent default where users must grant access first.
- Set per-publisher access
For each managed package publisher listed, choose Available to Administrators and Users, or Available to Administrators Only, depending on whether end users should be able to grant that vendor's support team access.
- Save and verify against the audit trail
Save the page, then confirm a test login-as session appears in the Setup Audit Trail with the admin name, target user, and timestamp so you know auditing is flowing.
Global toggle. When on, admins with Modify All Data and Manage Users can log in as any active user without a grant. Off by default; not available below Enterprise-level editions.
Per-publisher option that lets both end users and admins grant that package publisher's support team login access to an account.
Per-publisher option that limits granting to admins with Manage Users, so individual end users cannot expose their session to that publisher.
- The global toggle does not exist on Professional Edition or lower, and it may need Salesforce to provision it even on a qualifying edition.
- You cannot start a login-as session while already logged in as another user, and you cannot impersonate inactive users.
- Logging out after a login-as session also ends the admin's own session, so they will need to sign back in.
- Even with the global toggle on, Salesforce Support cannot use an admin's login to reach other users; Support access is always granted per user.
Prefer this walkthrough as its own page? How to Login Access Policies in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Control Login Access PoliciesSalesforce
- Grant Login AccessSalesforce
Straight from the source - Salesforce's reference material on Login Access Policies.
Hands-on resources to go deeper on Login Access Policies.
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. What capability does the Login Access Policies configuration govern?
Q2. By default, before an administrator can Login As a user, what must happen first?
Q3. Where is every Login As event recorded for compliance review?
Discussion
Loading discussion…