Event monitoring

One last feature that helps us keep our data secure is event monitoring, which is a tool that is meant to get granular details of user activity on our organization. These kinds of actions are called events. Tracking events ensures that we can identify abnormal organization usage.

You can monitor a great number of events, including logins (we already covered this information in the Monitoring the login history section), Visualforce page loads, API calls, and even report exports.

Events are available after 24 hours from when they are created and are readable from event log files. If we are using a developer edition organization, we can access all events, but they are limited to 1-day data retention period. If we are in enterprise, unlimited, or performance edition organizations, we have free access to logins, logouts, and insecure external asset event types with a 1-day data retention period. For an additional cost, we can get all event types with a 30-day data retention period.

Do you remember all the information that we can extract from the Login History page? Everything about the IPs, geolocation, client, and so on? With event monitoring, we can get a wide view of login events (for example, getting all the logins for a given time frame) and then scale down to get a given user or IP—for example, we can identify an anomaly in the number of logins and attribute it to a specific user, and then we can identify which clients that user is using and thereby find out that he is running buggy software.

Other than logins, we can monitor all sorts of stuff, such as data loss (as we already saw), user adoption (is the number of logins increasing?), or performance issues (Visualforce page loading time, API failures, and so on).

How do we get these files? For this, you have to put your technical hat on. We need to consume Salesforce APIs from the Workbench tool to get the event log files (you can use any other client, but this tool is quite easy to use and configure).

The steps are as follows:

1. Navigate to https://workbench.developerforce.com.
2. Select your organization type (production or sandbox; a developer edition organization is a production-like organization).

1. Click the Login with Salesforce button.
2. Enter your credentials.
3. Approve the Workbench app, as shown in the following screenshot:

What's happening here? We are unleashing an authentication method called OAuth2. This procedure allows Workbench to use Salesforce APIs on our behalf. By using the Workbench app, we can do all sort of things, such as queries, metadata deployments, and data manipulations. Workbench will take care of the low-level code needed to call Salesforce APIs.

After the successful login with Workbench, a new entry is shown in the Login History of our user (as shown in the following screenshot). Even though the user is logging in on their browser from Italy, the Workbench login comes from the USA. Why? Because Workbench servers are not located in Italy as Workbench is a cloud app that anyone can access from anywhere:

To access event log files, ensure that your profile has the API Enabled and View Event Log File permissions.

In Workbench, click on Queries | SOQL query, select the EventLogFile object, and enter the following SOQL query:

SELECT id, createddate, LogDate, EventType, LogFileLength, Interval FROM EventLogFile

The following is what you should get:

These are all events that occurred on our organization in the LogDate (despite the fact that the CreatedDate is one day later; remember that we said that events are available 24 hours after their execution).

If you don't have any record, wait for one day for your events to be properly stored.

To access the content of one of the records, copy its Salesforce ID (I'm choosing the Report event type), click on utilities | REST explorer, and input the following URL (be sure to select the GET option):

/services/data/v45.0/sobjects/EventLogFile/EVENT_LOG_ID

Click Execute and you'll get something like this:

This REST API gets all the information related to a given record. As the LogFile field contains all the data of the log, it is not returned on this kind of call, but requires a specific API endpoint to get the content (this is a common behavior for REST APIs dealing with objects).

Click on that link and you'll get the log content:

No surprises that it is a CSV file containing all the fields listed on the Report type event definition (you can read more at https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_eventlogfile_report.htm).

There's another cool app that you can use to download event log files. Check out the Salesforce Event Log File Browser available at https://salesforce-elf.herokuapp.com. Log in using the same procedure we used for Workbench and you should see the following result:

The most useful aspect of this app is the header filter and the one-click download of each CSV.

How do we analyze the data? There's an app for that called the Event Monitoring Analytics app, which is available for testing on a dedicated kind of developer edition organization, which comes with all the required data for you to have fun with event logs.

In the following example, we can identify an anomaly on Salesforce Report executions by user (this all comes from the Trailhead trail we referred to earlier):

It is possible to drill down to any user and see how they are behaving (in the previous screenshot, you can see that Bob is a suspicious user who is constantly running reports), but we also have information about reporting performances (we can spot slow-running reports and proactively inspect them to change filters to allow a quicker runtime).

It is even possible to schedule notification alarms if a certain metric bypasses a given threshold (for example, if the maximum runtime is over a certain number of seconds, or the number of reports downloaded exceeds a safeguard).