Login History
Login History is the Salesforce log of user authentication events.
Definition
Login History is the Salesforce log of user authentication events. Every time a user logs in, logs out, or has a session timeout, the platform records the event with the user identifier, timestamp, source IP address, login type, browser user agent, login status, and any associated Auth Provider, Connected App, or Identity Provider. The log is exposed in Setup, accessible to admins with the Manage Users permission, and downloadable as CSV for offline analysis.
The Login History is the primary forensic tool for "who logged in from where and when" questions. It complements the Setup Audit Trail (which records configuration changes) and Event Monitoring (which records fine-grained event activity). Where the audit trail tells you what was changed, the login history tells you who connected to the platform in the first place. For any security investigation, the standard order is: confirm the user logged in (Login History), confirm the user made the change (Setup Audit Trail), and confirm what data the user touched (Event Monitoring or Field History).
How Login History captures and exposes authentication events
What Login History records
Each entry in Login History captures the user identifier (username and user ID), the login timestamp, the source IP address, the login type (Application, Visualforce, OAuth, API), the user agent string from the browser or client, the login status (Success, Failed, Locked Out, Suspended), the geographic location derived from the IP, the platform (browser, mobile app, integration tool), the Connected App or Auth Provider used, and the session ID for cross-referencing. Failed login attempts are captured with the failure reason: Invalid Password, IP Restricted at Profile, IP Restricted at User, Locked Out, Restricted IP Range. The combination supports most forensic investigations.
Retention: 6 months at the UI, 1 year through the API
The Setup UI shows the most recent 6 months of login events. Beyond that, entries are purged from the UI but remain accessible through the LoginHistory object via SOQL and the SOAP/REST API for up to 1 year. After 1 year, entries are deleted from the platform unless an organization has archived them externally. For compliance-heavy industries, this is too short. The pattern is to schedule a monthly export from LoginHistory through Apex or Workbench, then archive externally. Event Monitoring (a paid add-on) provides more event types but the same time-bound model.
Querying LoginHistory through SOQL
LoginHistory is a queryable object in Salesforce. SELECT UserId, LoginTime, SourceIp, LoginType, Status, Application, Browser, Platform FROM LoginHistory WHERE LoginTime >= LAST_N_DAYS:30 ORDER BY LoginTime DESC returns the last 30 days of logins. The object supports filtering by UserId, LoginTime, Status, and SourceIp. Most admins use the Setup UI for quick lookups and the SOQL query for batch analysis or feeding into a SIEM. The query path is also how custom dashboards and alerting integrations consume login data.
Login types and what they mean
The LoginType field has several values worth knowing. Application Login is a standard web UI login through login.salesforce.com or a My Domain. Remote Access Client is OAuth authentication from a connected client (a script, a third-party app, a personal dev tool). Remote Access 2.0 is the modern OAuth 2.0 flow. Visualforce Login is access through a public Visualforce page. SAML Login is single sign-on through an external identity provider. Each type has its own forensic signature. A flood of Remote Access Client logins from an unusual IP is the signature of an integration credential leak. A burst of Visualforce Logins is usually a public Site that is suddenly under bot traffic.
Failed logins and the lockout pattern
Failed login attempts are captured separately from successful ones, with the Status field set to one of Invalid Password, Locked Out, Suspended, Disabled, Frozen, IP Restricted, or User Disabled. Five consecutive failed attempts trigger a temporary lockout (configurable in Password Policies). A repeated pattern of failed logins from the same IP across multiple users is the signature of a brute-force attack. Salesforce automatically rate-limits at the platform level, but the Login History is where you confirm the attack pattern. Transaction Security policies can also be configured to alert or block on this pattern.
Geo-location and impossible-travel detection
Each Login History entry includes a geographic location derived from the IP address. The location is approximate (city-level), not GPS-precise. Combining timestamps with locations enables impossible-travel detection: if user X logs in from New York at 2 PM and from Tokyo at 2:15 PM, one of the two events is suspicious. Salesforce Transaction Security includes a built-in policy template for this pattern, and many SIEM integrations replicate the logic externally. The geo-location is not always accurate for VPN users or mobile carriers, so the policy needs tolerance for false positives.
Login Flows and step-up authentication
Login Flows are screen flows that run after a successful password authentication but before the session is fully established. They can prompt for additional information, accept or reject the login based on context, or require multi-factor authentication. When a Login Flow runs, the Login History entry includes the Login Flow ID. This is how you trace a user who passed password authentication but failed a step-up challenge: the entry exists with a specific Status indicating the Login Flow rejected the session. Useful for any org running risk-based authentication on top of Salesforce.
Using Login History for authentication forensics
Login History is always on. You do not enable it. The configuration work is on the consumption side: knowing where to find it, how to filter it, and how to archive it for long-term retention.
- Open Login History
Setup, Quick Find Login History, click the link under Identity. The default view shows the most recent 1,000 login events with the default filter applied.
- Filter by user, date, IP, or status
Use the column filters: User Type, Username, Status, Login Time, Source IP. Combine filters with AND logic. The Source IP filter is the most useful one for "where is this user connecting from" investigations.
- Drill into a single entry
Click any row to open the detail view: timestamp, IP, user agent, browser, platform, Connected App, Auth Provider, Login Flow, Status. The detail view is what you need for forensic write-ups.
- Run a SOQL query for batch analysis
Workbench or Developer Console: SELECT UserId, LoginTime, SourceIp, LoginType, Status FROM LoginHistory WHERE LoginTime >= LAST_N_DAYS:90 returns 90 days of events. Export to CSV for analysis or feeding into a SIEM.
- Set up alerts on suspicious patterns
For real-time alerting, use Transaction Security policies. Built-in templates cover impossible-travel and concurrent-session patterns. Custom policies in Apex extend the alerting to your own logic.
- Schedule a monthly external archive
For retention beyond the 1-year API window, schedule a monthly export of LoginHistory through Apex or a CI job. Push to S3 or an on-prem SIEM. This is the canonical pattern for SOC 2 and ISO 27001 compliance.
Multi-field filter on the Setup, Login History page: User, Date, Status, Source IP, Application, Browser. Combines with AND logic.
Queryable object exposed through SOAP and REST API. Supports up to 1 year of history. Used for batch analysis and SIEM integration.
Application Login, Remote Access, Visualforce Login, SAML Login. Each type has different forensic signatures.
Success, Failed, Locked Out, Suspended, Disabled, Frozen, Restricted. Captures every authentication outcome.
Real-time policies that react to Login History patterns (impossible-travel, concurrent sessions, anomalous IPs).
- Login History retention is 6 months in the UI and 1 year through the API. Older events are gone unless you exported them. Schedule monthly archives for compliance.
- Geo-location is IP-based and approximate. VPN users and mobile carrier IPs can appear in unexpected cities, generating false positives in impossible-travel detection.
- Failed login attempts include the reason in the Status field. Use this to distinguish brute-force attempts from typo-driven lockouts. The patterns look similar without the reason code.
- OAuth-based access through Connected Apps is logged differently from password-based logins. The Connected App ID appears in the entry. Filter on Connected App for integration-specific forensics.
- Login Flows that reject a session still appear in Login History as Success entries with the Login Flow ID. Cross-reference with the Login Flow logs to see why the session was terminated.
Trust & references
Straight from the source - Salesforce's reference material on Login History.
- Monitor Login HistorySalesforce Help
- LoginHistory Object ReferenceSalesforce Developers
- Login ForensicsSalesforce Help
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. Why is understanding Login History important for Salesforce admins?
Q2. What is the primary benefit of Login History for Salesforce administrators?
Q3. Can a Salesforce admin configure Login History without writing code?
Discussion
Loading discussion…