Login Access Policies
Login Access Policies is the Salesforce Setup configuration that controls whether administrators can log in as another user (Login As) for support purposes.
Definition
Login Access Policies is the Salesforce Setup configuration that controls whether administrators can log in as another user (Login As) for support purposes. The setting governs the global Login As capability that lets an admin impersonate a target user to debug a problem or verify a configuration from that user's perspective. By default, administrators with Modify All Data can use Login As, but the target user must explicitly grant access through the Grant Account Login Access mechanism on their own User record, providing a time-limited window during which the admin can impersonate them.
The page also configures policy details: whether users can grant access for varying durations, whether certain administrator roles can bypass the grant requirement, and how Login As events are audited. Compliance-sensitive orgs tighten these settings beyond defaults; the impersonation capability is powerful and audit teams want strict controls around when and by whom it can be used. The Setup Audit Trail captures every Login As event with the admin name, target user name, and timestamp.
How Login Access Policies governs impersonation
The user-grants-access model
By default, even system administrators cannot use Login As without the target user explicitly granting access. The target user goes to their Personal Settings > Grant Account Login Access and chooses a duration (1 day to 1 year). During this window, the admin can use Login As; afterward, access expires. This consent-based model is the platform's privacy default, prevented surprise impersonation.
Administrator bypass option
Some orgs configure the policy to let administrators with specific permissions bypass the grant requirement. The Login Access Policies page exposes this configuration. The trade-off is operational speed (admins can help users without waiting for grant) versus privacy (admins can impersonate without explicit user consent). Most B2B orgs do not enable bypass; support-intensive operations may.
Salesforce support access
Beyond local admin access, Login Access Policies controls whether Salesforce Support engineers can log in as users for case troubleshooting. Granting support access goes through a separate flow but is governed by the same policy framework. Enable when filing a complex support case where the engineer needs to reproduce a user-specific issue.
Audit trail
Every Login As event produces a Setup Audit Trail entry with the admin name, target user name, and timestamp. Compliance teams expect this audit trail for any organization where Login As is enabled. Build a SIEM alert on unexpected Login As patterns (admin logging in as senior executives, repeated Login As to the same user).
User experience during Login As
When an admin uses Login As, the platform indicates the impersonation in the user interface (a banner showing "Logged in as <username>"). The admin sees what the target user sees but with the impersonation context evident. All actions taken during Login As are attributed to the admin in audit logs, not the target user; this is a deliberate distinction for accountability.
Limitations of Login As
Login As cannot impersonate certain users: users marked as Federation ID restricted, deactivated users, or users with very high permission levels in some cases. Some integrations and Connected App actions cannot be tested through Login As because the OAuth context differs. Plan for these edge cases; not all troubleshooting can be done through impersonation.
Best practices for support workflows
Establish a clear policy: when can support use Login As, what duration of grant is required, what documentation is needed afterward. Train support to confirm with the user before using Login As even when grant is in place. Document every Login As session in the support ticket; compliance audits expect to see this trail.
Configure Login Access Policies
Configuring Login Access Policies is a privacy and operational policy decision. The steps below cover the standard setup and the audit pattern that keeps the capability safe.
- Open the policy page
Setup > Security > Login Access Policies. The page shows current grant duration options and bypass settings.
- Decide on bypass policy
Default is no bypass: even admins need user grant. Decide whether your support workflow needs the bypass; document the decision and rationale.
- Configure grant duration options
Choose the durations users can select when granting access (1 day, 1 week, 1 month, etc.). Limit very long durations unless operationally needed.
- Train users on Grant Account Login Access
Personal Settings > Grant Account Login Access. Users need to know how and when to use this; without training, support cycles get stuck waiting for grants.
- Document admin policy
Write a clear policy: when can support use Login As, what user confirmation is needed, what documentation is required afterward.
- Set up SIEM alerts
Stream Setup Audit Trail to SIEM. Alert on unusual Login As patterns: high-privilege users targeted, frequency anomalies, off-hours impersonation.
- Audit quarterly
Review the Setup Audit Trail Login As entries. Confirm each impersonation was authorized; investigate any that lack documentation.
Default. User must explicitly grant for impersonation.
Allows specified admin permissions to skip the grant requirement.
Time windows the user can choose: 1 day to 1 year.
Separate flow for support engineers; governed by the same policy framework.
Every Login As event captured. Cannot be disabled.
- Bypass enables admins to impersonate without user consent. Privacy implications are significant; enable only with documented business need.
- Actions during Login As are attributed to the admin. Some admins assume actions are logged as the target user; communicate clearly.
- Some users cannot be impersonated (high-privilege, integration users, Federation ID restricted). Plan for these edge cases.
- Setup Audit Trail retention is finite. For long-horizon audit, export to SIEM.
- Connected App OAuth contexts differ during Login As. Some integration issues cannot be reproduced through impersonation.
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. In which area of Salesforce would you typically find Login Access Policies?
Q2. What is the primary benefit of Login Access Policies for Salesforce administrators?
Q3. Why is understanding Login Access Policies important for Salesforce admins?
Discussion
Loading discussion…