Query Event Log Files

Learning Objectives

After completing this unit, you’ll be able to:
  • Ensure that you have the correct permissions to use event monitoring.
  • Log in to and navigate to several tools in Workbench.
  • Query an EventLogFile object using the SOQL query editor and REST Explorer.
  • Compare and contrast the SOAP and REST APIs for querying event log files.
  • Describe the data type used to store the underlying log data.

Query Event Log Files in Workbench

Let’s consider one of the example cases from earlier. A sales representative named Rob Burgle left your company a few weeks ago and joined a major competitor. All of a sudden, you start losing deals to this other company. You suspect that Mr. Burgle downloaded a report containing confidential lead information and shared it with his new employer. Normally, you wouldn’t be able to confirm your suspicions. But with event monitoring, you can gather all the evidence you need to set the story straight. Let’s look at how this process works.

Before we get started, double-check that you have the correct permissions to query event log files. Event monitoring requires the “API Enabled” and “View Event Log File” permissions.


Shield Event Monitoring is available for free in Developer Edition orgs. All other editions require you to purchase a license.

Now we’re ready to go. The first step in our investigation is to log in to Workbench.
  1. Log in to your Trailhead DE organization and navigate to Workbench.
  2. For Environment, select Production. For API Version, select the highest available number. Make sure that you check I agree to the terms of service.
  3. Click Login with Salesforce.
You’ve arrived at the Workbench home page. We don’t cover all the tool’s features in this module, but we go through the pieces that are useful for event monitoring. Let’s start by using the SOQL query editor to make sure that you have some data to work with.
  1. In the top menu, select queries | SOQL Query.
  2. Under Object, choose EventLogFile. Under Fields, select count(). Notice that the editor populates with some query text.
  3. Click Query.

You should see something like this:

The count() function in the SOQL Query Editor.

The count() function returns how many EventLogFile records exist in your organization. If the response tells you “Query would return 0 records,” it means that you don’t have any stored events. Remember that it takes 24 hours for events to surface and the log files are only stored for 24 hours in DE organizations. If you don’t get any results back, you can retry tomorrow.

So what exactly does the EventLogFile object store? To find out, we can do what’s called an object describe:
  1. In the top menu, select info | Standard & Custom Objects.
  2. Select EventLogFile from the dropdown menu.
  3. Expand the Attributes menu to view the object’s properties. EventLogFile is queryable, which means that you can request information about the object from the database. It’s also retrievable, so you can find an EventLogFile record by its ID.
  4. Expand the Fields menu. There are 17 fields here, but let’s pay particular attention to two of them: EventType and LogFile.
    • EventType: This field displays which event types a record represents. If you expand EventType | Picklist Values, you can see the different types of events. In our case, we’re interested in records with an EventType of Report Export.
    • LogFile: This field is where the actual information you’re looking for is stored. The contents of a log file depend on the EventType. For Report Export, this field stores everything from the ID of the user that exported the report to the browser and operating system that they used to do it.

We’re getting closer to finding our culprit! Let’s keep collecting evidence by using another tool in Workbench: the REST Explorer.

View Events in the REST Explorer

The REST Explorer gives you access to the Salesforce REST API, a web service that lets you retrieve data from your organization.

To get more information about your organization’s Report Export events in Workbench:
  1. In the top menu, select utilities | REST Explorer.
  2. Replace the existing text with /services/data/v<APIversion>.0/query?q=SELECT+Id+,+EventType+,+LogDate+,+LogFileLength+,+LogFile+FROM+EventLogFile+ WHERE+EventType+=+'ReportExport', where <APIversion> is the API version you’re using, such as 46.
  3. Click Execute.

If no reports have been exported from your organization in the past 24 hours, the totalSize field has a value of zero. Remember that it takes 24 hours for events to become available. You can export a report from your organization and try again tomorrow. Alternatively, you can replace ReportExport with a different event type in your REST query (for example, Login).

If you have some report export events, your execution returns something like this:

The records the REST query returned.

Expand one of the records and click the LogFile link. The log contents look something like this:

The event log file from one of the returned records.

Yikes! How are we supposed to learn anything from this? Don’t worry, we’re not done yet.

Compare Query Methods for Event Monitoring

You’ve used a couple of tools in Workbench. First, you used the SOQL Query Editor to determine whether you had any events stored in your organization. You also performed an object describe to learn about the EventLogFile object. Finally, you used the REST Explorer to view your EventLogFile records. All these tools retrieve information from your organization, so what’s the difference between them?

The answer isn’t too surprising: The difference is in the underlying API.

The SOQL Query Editor and the object describe use what’s called the SOAP API. It’s a little different than the REST API that you used in the REST Explorer. One difference is that writing a query in the SOQL Query Editor is more straightforward than writing one in the REST Explorer. Let’s say we wanted to retrieve one of our log files.

In SOAP, it looks like:

A simple query in the SOQL Query Editor using the SOAP API.

In REST, we use:

A more complex query in the REST Explorer using the REST API.

The SOQL query is easier to understand and remember. So why did we decide to use REST instead? Let’s look at what happens when we execute these queries and view one of our log files.

In SOAP, the query returns something like this:

The unintelligible log file from the SOQL query.

The REST query returns this:

The slightly less unintelligible log file from the REST query.

Here, we see the other major difference between SOAP and REST when it comes to querying event log files. The returned log files are the same, but they’re presented in different formats. When you retrieve your event log files using SOAP, the result is a serialized, Base64 string. If your organization plans on using tools like MuleSoft or Informatica to work with event log files, you want to use SOAP to retrieve your data. REST, on the other hand, deserializes the log file. It’s still not pretty, but as you’ll see in the upcoming section, other tools can transform the REST results into an easy-to-read format.