Salesforce Dictionary - Free Salesforce GlossarySalesforce Dictionary
DictionaryLLogin Access Policies
AdministrationAdvanced

Login Access Policies

Login Access Policies is a Setup page where administrators control whether users can grant Salesforce support or other administrators temporary login access to their accounts.

§ 01

Definition

Login Access Policies is a Setup page where administrators control whether users can grant Salesforce support or other administrators temporary login access to their accounts. It also controls the maximum duration of login access grants and whether the option appears in users' personal settings.

§ 02

In plain English

👋 Study buddy

Here's a simple way to think about it: Login Access Policies decides whether anyone can shadow into a user's session. "Log in as" is a debugging superpower - and exactly the kind of feature attackers want too. The policy controls who can grant it and how long it lasts.

§ 03

Worked example

scenario · real-world use

The admin at FinServe Bank configures Login Access Policies to allow users to grant login access for a maximum of 7 days and restricts the option to only grant access to Salesforce Support (not other admins). When a user needs help troubleshooting an issue, they grant temporary access and the support team can log in as that user to diagnose the problem.

§ 04

Why Login Access Policies decide whether anyone can shadow into a user's session

When a user reports a problem nobody else can reproduce, the fastest path to diagnosis is sometimes to log in as them. Salesforce supports this through "grant login access" - the user authorizes another admin or a Salesforce support engineer to sign in as them for a defined window. Login Access Policies controls whether any of that is possible at all in your org, who can be granted access, and the maximum duration of any grant.

The reason this is a deliberate setting and not a default is that login-as is exactly the kind of feature attackers want too. A compromised admin who can grant themselves login access to any user has effectively taken over the org. Tighten the policy to the strictest level your support model can tolerate, require explicit user consent (don't allow admins to self-grant), keep the grant duration short, and audit every use through Login History.

§ 05

How to set up Login Access Policies

Login Access Policies control whether admins can grant themselves Login As access to other users. Login As lets an admin impersonate another user for support — but it's a powerful feature requiring careful policy. The Setup page configures the policies.

  1. Open Setup → Login Access Policies

    Setup gear → Quick Find: Login Access → Login Access Policies.

  2. Tick Administrators Can Log in as Any User

    Org-wide toggle. When ON, admins with the right permission can Login As anyone without per-user opt-in. When OFF, users must individually grant access.

  3. Configure per-user grant requirements

    When the org-wide toggle is OFF, each user can grant time-bound access via their personal settings — Settings → Personal Information → Grant Login Access.

  4. Save

    Policy applies. Login As is then governed by the policy.

Key options
Administrators Can Log in as Any Userremember

Org-wide toggle. ON = admins can impersonate anyone. OFF = users opt-in per-grant.

Grant Login Access duration (per-user)remember

When users opt-in, they pick a duration (1 day, 1 week, 1 month, indefinite).

Audit Trailremember

Login As actions are logged in Setup Audit Trail and Login History — both delegator and impersonated user are visible.

Gotchas
  • Administrators Can Log in as Any User is OFF by default in newer orgs. Enabling it makes Login As frictionless but increases blast radius if an admin account is compromised.
  • Login As actions are fully logged. Setup Audit Trail and Login History both record both the admin (delegator) and the impersonated user — pull from both columns when investigating.
  • Some user permissions can't be exercised via Login As — e.g. password reset for the impersonated user. Document the limits so admins don't get stuck mid-support.
§ 06

How organizations use Login Access Policies

Pacific Crest Bank

Tightened policy to require user consent and 1-hour max grants; security posture improved without breaking support workflows.

Atlas Manufacturing

Audited policy after a security review; previous defaults allowed admin self-grant which was deemed too permissive.

BlueRiver Health

Compliance team reviews login-access logs quarterly; user consent is now documented per grant.

Was this entry helpful?
Help us write better definitions. Quick reactions or detailed edit suggestions.
§

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…

Loading discussion…