The Force.com platform provides a lot of built in auditing capabilities to ensure that you can focus on what’s most important for your business. One of these foundational audit tools is Login History. The Login History audit trail enables administrators to download the last six months of logins to the Force.com platform, either via a CSV download link in the setup user interface or via the API. With Login History, you can only track login successes and failures by user, IP, application, API, or browser to name a few key attributes and data retain duration 6 months not more than that. To overcome these limitation, Salesforce released a new feature Login Forensics. With Login forensics, you can better determine which user behavior is legitimate to prevent identity fraud in Salesforce.
This feature is available in the following salesforce editions:
Enterprise, Performance, Unlimited, Developer Editions
Login forensics recognizes suspicious login movement. It gives key user access data, including:
- The average number of logins per user per a specified time-period.
- Who logged in more than the average number of times.
- Who logged in during non-business hours.
- Who logged in using suspicious IP ranges.
There’s some basic terminology to master before using this feature.
Enable Login Forensics: –
To enable login forensics, go to setup [Symbol] Logs [Symbol] Event Monitoring Setup. Enable Login Forensics. By enabling this, you can have this in our Salesforce org.

Normally an event refers to anything that occurs in Salesforce. Including user clicks, record state changes, and taking estimations of different values. Events are unchanging and timestamped, but login event is a single instance of a user logging in to an organization. It is very similar to login history in Salesforce.
Login History: –
Administrators can acquire by downloading the data to .cvs or .gzip document and it is accessible through Setup and the API. This data has ordering and history restrictions.
In app exchange, there are some packages available for additional feature.
Comparison of Login Forensics to Login History and Login Log Lines:
Feature | Login Forensics | Login History | Login Log Lines |
Standard Object or File | LoginEvent | LoginHistory | EventLogFile (Login event type) |
Data Duration Until Deleted | 10 years | 6 months | 30 days |
Storage | HBase | Oracle | Oracle |
Access | API | Setup UI, API | API download, Wave dashboard |
Permissions | View Login Forensics Events | Manage Users | View Event Log Files |
Extensibility | Yes, using AdditionalInfo field | No | No |
Packaging | Included with Event Monitoring add-on | Included with all orgs | Included with Event Monitoring add-on |
Administrators can track events using the LoginEvent object. There’s no user interface for login forensics. Use the Force.com IDE, Workbench, or other development tools to interact with this feature.
The LoginEvent object, which stores the raw login data, has a rowkey consisting only of EventTime (in a descending order) and the UniqueKey. The PlatformEventMetric object, which stores the hourly roll-up metrics, has rowkey consisting of EventType and EventTime (in a descending order). These simple rowkeys enable fast response using standard SOQL. You just need to know the time frame you want to query and in the case of metrics, which metric and for which time frame.

Take the average difference between the EventDate and the CreatedDate fields to see when the events were captured. The above picture shows the time differences.
Login events are retained for 10 years by default. Because login forensics uses an asynchronous queuing technology similar to @future calls in Apex, login data can be delayed when querying.
There’s even the capacity to bring your own metadata into the login flow to further unique mark user’s login profile and identify irregularities in the login process. It’s the capacity to present own data through a HTTP Header. This can be done via the browser, a proxy, or API authentication. For instance, might want to register header name (e.g. “x-sfdc-addinfo-correlationid”) and value (e.g. “d18c5a3f-4fba-47bd-bbf8-6bb9a1786624”). Then, when you look at your login events, you just need to look for any logins that do not have this identifier to investigate further.

Finally, there’s a transaction tye that is vital to the process. Every Login Event can be traced back to a single Login History Id. This is useful for a couple of reasons. The first one is that Login History connects to Login Geo which captures geographical information like latitude and longitude of your users. Results can use the composite API to orchestrate un-related queries to generate the location of every user onto a mapping service like Google Maps. Secondly, with each resulting action where the user associates with data like looking at accounts, will have capacity to track every interaction back to a single Login on both the Login Event and Login History objects. For example, when tracking down which records were viewed from an API query. After six months, when Login History is deleted, you’ll continue to be able to track every interaction back to a single login for nine and half years more. So even logins via iPhone, Nexus tablet, Chrome browser on Mac, and Salesforce for Outlook can separate each set of transactions and link them back to a single login for the next ten years.

Conclusion:
Login forensics is an intelligence feature which gives the number of logins to an org on a daily—even hourly—basis.