Event Monitoring


Monitoring events in salesforce is not the same as debugging, so don’t get confused!

First, I am copying an pasting out of trailhead, because this is a ton of info, and I want it all in one resource. So, if you really want to learn it go here: Trailhead Event Monitoring

This is a correction to the trailhead training; event monitoring currently (05/05/2016) can be used with 32 different file types not 29 as stated:

  • Apex Callout
  • Apex Execution
  • Apex SOAP
  • Apex Trigger
  • API
  • Async Report
  • Bulk API
  • Change Set Operation
  • Content Distribution
  • Content Document Link
  • Content Transfer
  • Dashboard
  • Document Attachment Downloads
  • Login
  • Login As
  • Logout
  • MDAPI Operation
  • Multiblock Report
  • Package Install
  • Queued Execution
  • Report
  • Report Export
  • REST API
  • Salesforce1 Adoption (UI Tracking)
  • Sandbox
  • Sites
  • Time-Based Workflow
  • URI
  • Visualforce
  • Wave Change
  • Wave Interaction
  • Wave Performance

What Is Event Monitoring?

Everyone knows that being a detective is one of the coolest jobs you can have. Well, hold on to your magnifying glass because your job as a Salesforce administrator is about to get a whole lot cooler. With event monitoring, you can be the investigator your organization always needed.

Event monitoring is one of many tools that Salesforce provides to help keep your data secure. It lets you see the granular details of user activity in your organization. We refer to these user activities as events. You can view information about individual events or track trends in events to swiftly identify abnormal behavior and safeguard your company’s data.

So what are some of the events that you can track? Event monitoring provides tracking for 29 different types of events, including:

  • Logins
  • Logouts
  • URI (web clicks)
  • UITracking (mobile clicks)
  • Visualforce page loads
  • API calls
  • Apex executions
  • Report exports

All these events are stored in event log files. An event log file is generated when an event occurs in your organization and is available to view and download after 24 hours. The event types you can access and how long the files remain available depends on your edition.

  • Developer Edition (DE) organizations have free access to all 29 log types with one-day data retention.
  • Enterprise, Unlimited, and Performance Edition organizations have free access to the login and logout log files with one-day data retention. For an extra cost, you can access all log file types with 30-day data retention.

So how can you use event log files to become an all-knowing Salesforce super-sleuth? Let’s take login activity as an example. We’ll talk about accessing, downloading, and visualizing event log files later on. For now, assume that we did these steps and produced this graph of login activity.

Chart of the organization's login activity.

You can see that an unusually high number of logins to the organization occurred between May 4 and May 5. But how do you figure out exactly what happened during that time period? Luckily, event monitoring provides several ways for you to dig into this data. In this case, you might want to break down the number of logins by user.

Chart of the organization's login activity and login activity by user.

Adam Admin logged in 103 times! Something is definitely fishy. You can continue to break this data down to see things like how many distinct IP addresses a user logged in from. This information helps you pinpoint whether an outside party compromised a user’s account or whether a user is up to no good.

You’re probably beginning to see the power of event monitoring, but let’s consider some other uses.

  • Monitor data loss—Imagine that a sales representative leaves your company and joins a major competitor. Later, you find out that your organization is losing deal after deal to this other company. You suspect that your former employee downloaded a report containing leads and shared it with the competition. If you’d been using event monitoring, you could have caught this bad behavior before it cost your company sales.
  • Increase adoption—Event monitoring isn’t just for catching your users’ bad behavior. It can also alert you to parts of your organization that aren’t performing well. For example, you just rolled out a new Visualforce page in your organization that combines accounts and contacts and allows end users to add custom fields. Without any metrics, it’s difficult to tell how users are interacting with this page—if at all. Event monitoring helps you figure out which parts of your organization need increased adoption efforts and even helps you identify areas that need redevelopment.
  • Optimize performance—Sometimes it’s hard to determine the cause of slow page performance in your organization. Imagine that your company has an office in San Francisco and one in London. The users in London tell you that their reports are running slowly or even timing out. You can use event monitoring to determine whether the cause is related to a network issue in London or with the way your app is configured.

These cases are just a few ways that you can use event monitoring to keep your organization secure and running smoothly. Check out all the event types to discover what else you can do.

A Quick Note About the API

If you’re an administrator, working with the API can be daunting. We won’t go over all the nitty-gritty details in this module, but let’s take a minute to review some basics. API stands for Application Programming Interface. You can think of it as a bridge between an application (in our case, Salesforce) and the database. Two important terms to remember when working with the API are:

  • Objects—Almost every object in the user interface is also an object in the API (for example, Account or Case). The APIalso has several objects that you can’t use in the user interface.
  • Fields—The fields you’re used to seeing in the user interface are also fields in the API (for example, the Account Namefield in the user interface becomes the Name field in the API).

Sometimes, the user interface doesn’t provide you with every possible access point to your data. That’s why the API is so important. Salesforce encourages what’s called an API first approach to development. API first means that, before you develop an application’s user experience, you want to pay attention to the underlying API. The API lets you use your data in ways that aren’t possible in the user interface. Considering the API in the initial planning stages lets you develop a more robust application.

Event monitoring is an API-only feature. It isn’t anywhere in the Setup area. Instead, each organization’s event log files are stored in an API object called EventLogFile. Salesforce provides an API tool called Workbench that lets you access your EventLogFile objects. If all this information sounds a little confusing, don’t worry. We’ll go through everything step-by-step during this module.

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 15 fields here, but let’s pay particular attention to two of them: EventType andLogFile.
    • EventType: This field displays which of the 29 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 <API version> .0/query?q=SELECT+Id+,+EventType+,+LogDate+,+LogFileLength+,+LogFile+FROM+EventLogFile+WHERE+EventType+=+'ReportExport'.
  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 APIthat 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 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.

Download Event Log Files

You can use Workbench to quickly check your organization’s recent events and filter the events using certain criteria. But because you’re accessing the data through the API, you can also use other tools that make it even easier to work with event log files. To maximize the benefits of event monitoring, you want to download your event log files from Salesforceso that you can track them over time.

You can download event log files in several ways, including:

  • Direct download via the Event Log File browser application
  • cURL script
  • Python script

Let’s look at each approach.

Download Logs from Your Browser

Using the event log file browser application is the most straightforward approach to downloading your organization’s event monitoring data. Let’s check it out.

  1. Log in to your Trailhead DE organization.
  2. Navigate to the event log file browser application.
  3. Click Production Login.
  4. Enter a date range for your search.
  5. Enter an event type for your search.
  6. Click Apply.

You’ll see something like this:

The event log file browser page.

Note: If your organization doesn’t have any events in the specified date range or type, the page displays an error.

The list shows the same event log files that you see when you query the EventLogFile object using the REST Explorer in Workbench. You can’t open the files in the browser application, but you can directly download them or use a script. Let’s look at the direct download method.

Click the The direct download button. button to download a log to a comma-separated value (.csv) file. The ugly string of text that you saw in the REST Explorer is transformed into a format that’s easily readable in a spreadsheet application, like Microsoft Excel or Google Sheets. Each file contains all the events of a particular type that occurred in your organization in the past 24 hours.

Download the ReportExport log file. Open it in a spreadsheet, and let’s see what we can find.

 

Note: If you don’t have any report export events, download another type of event log file or export a report and try this step again tomorrow. Events do not appear in the log file until 24 hours after they occur.

The directly downloaded .csv format of the event log file.

That looks much better! Now we can finally figure out how that confidential information got leaked. Let’s say that our lead report’s ID is 00O30000008a3De. The URI field contains the ID of the report that was exported, and the USER_IDfield contains the ID of the user who exported that report. All this information helps you pinpoint the culprit.

The user ID and report ID from the event log file match that of our suspect and report, respectively.

The user ID and the report ID are a match! You now have enough evidence to confirm that Rob Burgle exported the report. Now it’s time for justice to be served!

Download Event Log Files Using cURL

We know that you’re excited about cracking your first case, but this victory is only the beginning of your illustrious career as a Salesforce administrator/detective. Each event type also has a The script download button. button that downloads a cURL script that you can run in your computer’s command line. cURL is one of many command-line tools that you can use to download data from your organization. The script downloads a .csv file exactly like the one you downloaded in the previous step. So why use cURL instead of the direct download tool?

Although using cURL is more complicated than the first method, it provides additional flexibility in working with event log files. Rather than manually downloading log files, you can schedule when to run the script so that you always have the most recent event log files for your organization. You can also transform your data so that it’s in a format that you want. If your organization has an integration specialist you can pass off these scripts to kickstart automation efforts.

 

Note: cURL is best-suited for Mac and Linux users. It’s possible to use it on Windows, but it requires additional configuration.

Using a cURL script to download your event log files requires the following:

  1. Providing your Salesforce credentials
  2. Logging in using oAuth and getting an access token
  3. Using a REST query to specify which logs you’re looking for

     

    Note: If you’re scheduling a recurring download, this step is important. You can use something like this query to filter events by the current day.

    1 https://${instance}.salesforce.com/services/data/v34.0/query?q=Select+Id+,+EventType+,+LogDate+From+EventLogFile+Where+LogDate+=+${day}
  4. Parsing the results of the query so that you can do things like create a date-based file structure—you can perform any transformations on your data that you want

For more information on using cURL with event log files, see this post.

Download Event Log Files Using Python

If you need a more programmatic way of downloading your organization’s event log files, you can use Python scripts. One advantage of using a Python script over a cURL script is that it’s easier for Windows users to work with, but it’s also suitable for Mac and Linux users.

Python is easy to understand, even if you’re not an experienced programmer. Some setup is required, but after that you can easily run your download script. For more information and to download the code, see this post.

Visualize Event Log File Data

Now that you’ve taken the time to learn about event log files and how to download them from Salesforce, it’s time to talk about visualization. Searching for a specific piece of information in thousands of rows in a spreadsheet is like searching for a needle in a haystack. Most of the time, it’s not useful to look for a single instance of a report export or user login. You’re probably more interested in noticing behavior that’s out of the ordinary. To get immediate insights into your organization’s inner workings, you can regularly download your event log files and create visual representations of your data.

Event monitoring doesn’t come with a visualization tool, but several existing tools are available to beautify your data. Some provide specific support for event log files, while others require more setup. We won’t go into the details of each platform, but check out this list for some ideas.

  • Admin Analytics App for Wave (Pilot)—The Admin Analytics app for the Wave platform is a way to get insights into your event monitoring data without ever leaving the platform. Your data is automatically loaded from Salesforce to the app so you always get the most recent (and most stunning) visualization of what’s going on in your org. The app provides a collection of dashboards that use pre-integrated event data, so it’s a great way to get started with event monitoring. We’re still in pilot right now, but all you have to do is call your AE to start working with Admin Analytics.
    A dashboard displaying Login event data.
  • Splunk App for Salesforce—The app lets you analyze and visualize your organization’s use of Salesforce and gain insights into security, performance, and user behavior.
  • CloudLock and CloudLock Viewer—CloudLock, a cloud security provider, offers CloudLock for Force.com and the free CloudLock Event Monitoring Viewer. These tools give security professionals and internal auditors insight into event log files.
    CloudLock Viewer for event monitoring.
  • ezCloudAudit—Transforms event log files into easy-to-read tables and presents aggregated data in dynamic charts and graphs. ezCloudAudit tracks everything a user views in Salesforce, enabling you to drive user adoption, identify employee transgressions, and streamline auditing and compliance.
  • SkyHigh Networks—Provides a network proxy solution for cloud discovery and integrates with event log files to enrich user activity tracking for security and compliance concerns.
  • FairWarning—Protects sensitive information held in Salesforce by centrally applying security and governance policies across all your Salesforce organizations. FairWarning installation takes 30 minutes from the AppExchange.
  • New Relic Insights—This solution for Salesforce makes it simple to understand newly available rich data about your organization’s activity. Automatically import your event monitoring data into Insights to power your easy-to-build dashboards and instantly query your data in the user interface.
  • Palerra—The LORIC platform from Palerra secures data within Salesforce using machine learning and data science to analyze event log files and recognize anomalous user behavior. It enables administrators to manage auditing and compliance while increasing operational efficiency.

You now have an idea of what event monitoring can do for your organization. You’ve used event log files to solve a case and seen the many possibilities for downloading and visualizing your organization’s events. Now you have the tools you need to investigate, secure, and improve your organization. Good luck, detective.