23 December 2015

A Salesforce Wave App for Comparing Permissions








14 December 2015

Derived Fields or Getting to Last Week's Top Ten by Name Instead of by Id

Last December, I blogged about how to work with timestamps in Event Log Files. The basic idea is that we generate timestamps in the form of a number that looks like this: 20151210160337.6. Only, it's not a number really, it's a string. For instance, when you add a couple more characters, you get: 2015-12-10T16:03:37.600Z. Look more familiar? More importantly, as an ISO 8601 formatted date time type, it's easier to integrate with third party analytic platforms for trending and time series charting.

The same can be said of of other fields like the ubiquitous USER_ID field which is stored as fifteen characters: 005B0000001WamP. However, in order to integrate with an analytics platform like Wave or Splunk, having the standard eighteen character id like 005B0000001WamPIAS makes it much easier to match with the actual User sObject so that you can retrieve other values such as the user's profile or role. The same can be true of any other object that you would want to denormalize so that you can create a report on the top ten users or reports by name instead of by id.

In Winter '16, we introduced derived fields as a sleepy enhancement to Event Log Files. It is sleepy in that there is no ticker tape parade, no marketing campaigns, no clappies at Dreamforce. Instead, it's a simple and effective way of transforming data when the file is generated based on patterns and data already contained within the file. It's TEL (Transform, Extract, and Load) instead of ETL (Extract, Transform, and Load).

The original data doesn't go away. Instead, a new field is added with a '_DERIVED' suffix. That way existing integrations won't break and options exist for other kinds of non-standard transformations. For instance, the fifteen character USER_ID now has a counterpart with an eighteen character USER_ID_DERIVED and the TIMESTAMP has a TIMESTAMP_DERIVED equivelent. This opens new doors to future transformations.

This means applications like Wave Analytics can more easily augment or join data based on these transformed ids and timestamps.

As a result reports look like this

instead of like this

Derived fields with Event Log Files handles the problem of data preparation by transforming the data before the file is generated, making future transformations easier. Hope this helps with your integrations!

09 November 2015

Using the Setup Audit Trail API - the best kept secret of Winter '16

The Setup Audit Trail has been around for a long time. It's part of the Salesforce trust platform and is built into every edition. It tracks changes in setup by administrators such as adding new users, activation of users, changes in permissions including escalations of privilege, and changes to metadata like the creation of fields or deletion of objects. 

Until very recently, Setup Audit Trail was only available to manually download to a CSV (comma separated values) file using a link on a page in setup. I kept hearing how customers hated putting manual processes in place to click the link once a month as well as merge newly downloaded CSV files into previous exports. It made audit and compliance use cases much harder than what anyone wanted. Everyone was asking to integrate the Setup Audit Trail using the API so they could schedule regular, automated downloads of audit trail data to analytics and SIEM tools.

Starting with Winter '16, we added the Setup Audit Trail to the API as the SetupAuditTrail sObject. There are a couple key use cases that you might want to try out using a tool like Workbench.

1. I want to know everyone who logged in as a particular end-user:
SELECT Action, CreatedById, CreatedDate, DelegateUser, Display, Id, Section 
FROM SetupAuditTrail 
WHERE CreatedBy.Name = 'Jim Rivera' 

2. I want to know everyone an admin user logged in as:
SELECT Action, CreatedBy.Name, CreatedDate, DelegateUser, Display, Id, Section 
FROM SetupAuditTrail 
WHERE DelegateUser = 'at@xx.com' 

3. I want to know everything that any users with a specific profile (or role) did in setup:
SELECT Action, CreatedBy.Profile.Name, CreatedDate, DelegateUser, Display, Id, Section 
FROM SetupAuditTrail 
WHERE CreatedBy.Profile.Name = 'EMEA VP' 

4. I want to know every user who was 'frozen' in the last week
FROM SetupAuditTrail 
WHERE Action = 'frozeuser' AND CreatedDate = Last_n_Days:7 

5. I want to know everything a specific user did last week
FROM SetupAuditTrail 
WHERE CreatedBy.Name = 'Adrian Kunzle' AND CreatedDate = Last_n_Days:7 

I use 'Limit 10' to just test the queries and keep them from taking a long time to return which is a good idea when experimenting with new queries.

Once you know what kind of queries you can write, you can create incredible apps that combine the SetupAuditTrail API with an app building platform like Node.js on Heroku:
The application above was created by the incredible Alessandro. You can download the source code from his Github repository or try it out with this free Heroku app.

You can also explore Setup Audit Trail data using an analytics platform like Wave:

The Setup Audit Trail is a powerful way of tracking important administrative audit events and now it's even more accessible through the API.

02 November 2015

These are a few of my favorite things

Event Monitoring provides easily downloadable CSV(Comma Separated Value) log files. The value of this data is really in the insights that you gain from rolling up and aggregating the data based on questions like:
  1. how many accounts were accessed in the last week?
  2. how many reports were downloaded by a specific user in the last 6 months?
  3. how many total executions did I have in the past year?
  4. how big are the files that I need to store on an ongoing basis for regulatory reasons?
Normally you would spend time to integrate, enrich, and analyze log data using an analytics platform. We have a great app ecosystem of ISV (Independent Software Vendors) that provide pre-built insights into this data.

But sometimes you just want a quick and easy way to answer this data without first creating an integration or enriching the data. In particular, you may want to analyze the data when it ranges over extremely long periods of time and significant volumes of data that you may not already have integrated into your analytics platform of choice. This actually came up in conversation with a customer administrator who told me that he was downloading Event Log Files and using a command line tool called grep to ask simple questions about the data; in effect he was trying to find a needle in the log file haystack without using an analytics platform.

Event Log Files generate CSV log file content. As a result, it's easy to report on it using piping in a Unix based CLI (Command Line Interface or Terminal).  This is definitely not for the button click crowd but it's incredibly fast and efficient for processing large amounts of data quickly. And since it's a good idea to keep a source system of files for a long period of time, you can always write quick piping commands to answer ad-hoc questions that may come up where you don't want to first stage or munge the data into an analytics platform.

If you haven't ever worked with a CLI (Command Line Interface or Terminal), I recommend first reading this great blog post from Lifehacker or this DataVu blog post. Also, if you're a windows only user, I wouldn't really continue with this post unless your files are on a unix based system like Mac or Linux that you can SSH into.

Here a few of my favorite things when it comes to commands to CLI prompts:

Use case: login to the file server where you're keeping the source log files
Example Prompt: ssh username@boxname
Notes: you'll need a password which means if you don't own that server, you'll need to request access

Use case: navigate to the directory where the log files are for a specific date (assuming you're storing them by date rather than by type or something else)
Example Prompt: cd Documents/logs/2015-09-30
Notes: if you don't manage this server, you'll need to find out where the files are first

Use case: list the files based on last modified date
Example Prompt: ls -tr
Example Output:
Notes: I love this command. It's super simple and assumes you're dealing with the latest change first.

Use case: list the files based on size sorted from largest to smallest
Example Prompt: ls -less | sort -n -r
Example Output:
4116672 -rw-r--r--  1 auser  SFDC\Domain Users  2107733241 Oct  1 21:43 ApexTrigger-2015-09-30.csv
3512792 -rw-r--r--  1 auser  SFDC\Domain Users  1798546132 Oct  1 21:53 UITracking-2015-09-30.csv
3437816 -rw-r--r--  1 auser  SFDC\Domain Users  1760159289 Oct  1 21:58 URI-2015-09-30.csv
Notes: This is really helpful for finding the size of files, for instance if you just want to view the smallest file as a sample data set.

Use case: view the entire file in the terminal
Example Prompt: cat PackageInstall-2015-09-30.csv
Example Output:
"PackageInstall","20150930175506.083","4-YHvN7eC7w3t6H5TippD-","00D000000000062","0053000000BqwWz","175","","","","INSTALL","0","0","0","0","SOS Quick Setup & Dashboard","OTHER","2015-09-30T17:55:06.083Z","0053000000BqwWzAAJ"
"PackageInstall","20150930175953.848","4-YIEBVUUMqV2bH5Tiluk-","00D000000000062","0053000000BqwWz","96","","","","INSTALL","0","0","0","0","SOS Quick Setup
Notes: This is really helpful for small files but can be overwhelming when you have a larger one unless you first reduce the output using a command like grep.

Use case: only view the first 10 lines of a file
Example Prompt: head -10 ApexTrigger-2015-09-30.csv
Example Output:
Notes: This is really helpful for really large files when you want to quickly validate the file headers with some sample data without having to load all of the data to the terminal or first reduce the data using a command like grep.

Use case: only view the last 10 lines of a file
Example Prompt: tail -10 ApexTrigger-2015-09-30.csv
Example Output:
Notes: This is really helpful for really large files to find when and where the file ends without having to load all of the data to there terminal. Several times, I had questions where the file ended and when the last events were processed for the day. Tail helps me to find out where the file and day ends.

Use case: find out how many total transactions you had for a day, sorted from highest to lowest
Example Prompt: wc -cl /Users/atorman/Documents/logs/2015-09-30/*.csv | sort -n -r 
Example Output:
31129864 9577494169 total
8904594 2107733241 /Users/auser/Documents/logs/2015-09-30/ApexTrigger-2015-09-30.csv
5655267 1760159289 /Users/auser/Documents/logs/2015-09-30/URI-2015-09-30.csv
Notes: This is really helpful for capacity planning or for quick questions around total transactions by file type or date. I'm often asked how many log lines were generated or how big the files are that we're collecting. This is also really easy to output to a CSV so you can provide the information to another person. Just change the prompt to wc -cl /Users/atorman/Documents/logs/ | sort -n -r >> lineCount.csv.

Use case: simple report on number of lines by file type (*.csv)
Example Prompt: du -a *.csv | sort -n -r 
Example Output:
1676752 UITracking-2015-11-01.csv
1094160 ApexExecution-2015-11-01.csv
554040 ApexSoap-2015-11-01.csv
443408 RestApi-2015-11-01.csv
276112 URI-2015-11-01.csv
Notes: Similar to wc -l, du helps with capacity planning and enables you to answer quick questions around total transactions for a file or event type.

Use case: simple report on size by file type (*.csv)
Example Prompt: du -hs *.csv | sort -n
Example Output:
1.4M ApexCallout-2015-11-01.csv
1.7M TimeBasedWorkflow-2015-11-01.csv
3.2M QueuedExecution-2015-11-01.csv
3.6M Logout-2015-11-01.csv
5.7M Report-2015-11-01.csv
Notes: Similar to wc -c, helps with capacity planning and to answer quick questions around total transactions for a file or event type.

Use case: merge multiple CSV files together into a new CSV
Example Prompt: Merge cat *.csv > new.csv
Notes: This is really helpful when merging multiple files of the same type (e.g. API) that span multiple days into a single CSV prior to loading to an analytics platform.

Use case: get all of the report export log lines for a specific user (e.g. '00530000000h51Z')
Example Prompt: grep -r '00530000000h51Z' 2015*/ReportExport*.csv
Example Output:
2015-10-13/ReportExport-2015-10-13.csv:"ReportExport","20151013205624.313","4-nPScfLnMsalbH5Tipnt-","00D000000000062","00530000000h51Z","","","","/00O30000008ZXB4","Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36"
Notes: I <3 grep! Grep is basically a simple search, and as a result, is a good tool for finding a needle in the haystack of log lines. Grep is really helpful for providing a quick audit report for your auditors on everything a specific user did. It's also really powerful to combine this with other commands by using a pipe (i.e. '|'). For instance, by adding '| wc -l' to the end of the above command, you can get the total number of reports the user exported instead of the specific report log lines. This is similar to performing a count() in SOQL and filtering by a specific user Id. Now you're using the command line for reporting purposes!

Use case: get all of the events where an account was accessed
Example Prompt: grep 'EVENT_TYPE\|/001' URI*.csv | head -10
Example Output:
Notes: This is really helpful for providing a quick audit report for your auditors on account access. This is also another good prompt to add '| wc -l' to in order to find out how many times a specific account was accessed.

Use case: convert timestamp from a number to a string prior to importing to a reporting application
Example Prompt: awk -F ','  '{ if(NR==1) printf("%s\n",$0); else{ for(i=1;i<=NF;i++) { if(i>1&& i<=NF) printf("%s",","); if(i == 2) printf "\"%s-%s-%sT%s:%s:%sZ\"", substr($2,2,4),substr($2,6,2),substr($2,8,2),substr($2,10,2),substr($2,12,2),substr($2,14,2); else printf ("%s",$i);  if(i==NF) printf("\n")}}}' "${eventTypes[$i]}-raw/${eventTypes[$i]}-${logDates[$i]}.csv" > "${eventTypes[$i]}/${eventTypes[$i]}-${logDates[$i]}.csv"
Notes: this one takes a lot more work but is really helpful for transforming data before loading it into a system that has specific formatting requirements.

There are many more great utilities available on the command line, which when coupled with pipes (|) and shell scripts makes for an easy way to automate many simple tasks or perform ad-hoc queries against the raw log files.

And those are a few of my favorite things!

29 October 2015




Lets start with the definition of each:
  • CreatedDate tracks when the log file was generated.









Select LogFile from EventLogFile where LogDate=Last_n_Days:7



Select LogFile from EventLogFile where CreatedDate=Last_n_Days:7




19 October 2015

ELF on ELK on Docker

The ELF on ELK on Docker repository is available!







It consists of three key solutions:

  1. download the ELF on ELK from Github
  2. change the sfdc_elf.config file (add authorization credentials)
  3. run Docker from the terminal




Let us know what you think!

12 October 2015

IdeaExchange 50K Club

Platform Monitoring team at Salesforce


And in that time we closed some of the following ideas:




09 October 2015

Cause and Consequence: Need of real time security actions








Building Real Time Security Policies


We currently support four (4) different event types:
  1. Login - for user sessions
  4. AccessResource - for connected apps, reports and dashboards





Next Steps





05 October 2015

Event Monitoring Trailhead Module



But what exactly is trailhead?


Why is the team make up important?




For a couple of reasons:
  5. It's free to sign up and use.


03 August 2015

Who saw the CEO's pension record?

That's how the use case starts. It's like a game of Clue; it's very open ended and leaves a lot of open questions that need to be answered like:
  • why is it important to track this?
  • who really needs this information? Legal, risk, admin, an auditor, etc...
  • do you need to know every / any place where the data was 'seen' like a report view, list view, search result, API query, lookup, or any of the other ways you can access data on the platform or just when they drill into the record detail (e.g. is it sufficient to just track who clicked into the record)?
  • what data did they see when they saw the record; in particular did they see PII (personally identifiable information) or sensitive (salary, amount invested, diagnosis, etc...) data?
  • what did they do with the data after they saw it?
  • most importantly, once they have this information, what will they do with it? Take an employee to court, terminate, put them up on a wall of shame, document for a regulator?
These are difficult questions. Regardless of the answers, there are a lot of things Event Monitoring can do to help with this use case.

Since the primary case was answering who saw the CEO's pension record, lets walk through that example with Event Monitoring.

It starts with a record id. Did you ever notice that when you view a record, the browser address bar shows the record id?

A record id is an immutable (which means it can't be edited), fifteen character, unique record locator. Because it never changes, you can always find the record it belongs to. All you have to do is drop it in the address bar or use the API to query based on the id. That way, even if you rename the record, we'll always be able to track down the original easily.

As a result, every time a user clicks into a record, we capture that id in the address bar. It's possible we capture more information as well, for instance, whether the record was transferred, edited, cloned, or printed. The key here is that there has to be a server interaction that changes the address in the browser address bar. So if you click a link that only changes something in the browser, we won't capture it. But if the screen refreshes with a new link in the address bar, chances are we've captured it in the URI log file.

In the case of the CEO's pension record, we clicked into the record:

As a result, we can track this in the URI log file:

The log file won't tell us the name of the record or any details like the CEO's pension amount; however, we can always query the API to find out more about the record that was accessed:

Now it's possible that we saw the CEO's pension record in a report:

We'll track that the report was accessed in both the Report and URI log files, but we won't list the records that were viewed like the CEO's pension record. However, if the user clicked into the record from the report, we'll capture the click through.

In addition, if the user exported the results from the report, we won't know that the user exported the CEO's pension record; however, we will be able to identify the criteria used in the report and the fields included in the export in the Report Export log file:

Similarly, a user might search for the CEO's pension record:

We won't store the records viewed in the search results nor the field values that were viewed; however, if you click into the record from a search view, we do capture both the record id and the search position from the address bar:

And if the user accesses the pension record from an integrated application using the API, we'll know if they queried (SOQL) or searched (SOSL) the pension object, but not the specific results from the query unless they updated it through the API:

Event Monitoring captures a lot of data for many different use cases. Understanding specifically what it captures from what it doesn't helps ensure we meet the right use case each time.

28 July 2015

Who stole the cookie from the cookie jar?

Sample Visualforce Page using Google Charting API



  • Who saw what data
  • When they saw that data
  • Where they accessed the data
  • What fields they accessed
  • How long a query took
  • How many records they accessed


Each event consists of key information about the API transaction including:

  • AdditionalInfo
  • ApiType
  • ApiVersion
  • Client
  • ElapsedTime
  • EventTime
  • Id
  • LoginHistoryId
  • ObjectType
  • Operation
  • RowsProcessed
  • Soql
  • SourceIp
  • UserAgent
  • UserId
  • Username




13 July 2015

Track your Apex limits in production using Apex Limit Events


Example of an app you can build with the
Apex Limit Events Pilot




  • EntryPointId
  • EntryPointName
  • EntryPointType
  • EventTime
  • ExecutionIdentifier
  • Id
  • LimitType
  • LimitValue
  • NamespacePrefix
  • UserId
  • Username
Each hourly metric consists of key aggregate information including:
  • Distinct Number of Apex Transactions
  • Distinct Number of Apex Transactions With Limits Exceeding 60% Threshold
  • Average Limit Value By Entry Point Name
  • Average Limit Value By Limit Type




09 June 2015

The Salesforce Hacker Way

This post is dedicated to the innovation exchange students who visited Salesforce on their recent tour of Silicon Valley companies. Innovation exchange is a summer program offered by my alma mater, James Madison University (JMU).

As JMU alumni, a couple of us here at Salesforce hosted a question and answer session for the students in this program. The panel members came from product, engineering, design, and analyst relations.

The students came prepared with a set of great questions like:

  • How do you know when you have enough product to launch?
  • How do you know when to kill a product?
  • How do you take an idea to market?
  • How is Salesforce different from Dropbox?
  • Who competes with Salesforce?
  • How do you get a job out of college?

We shared our perspective about what it means to work as a team building products that customers love. We talked about ideas like launch vehicles (e.g. pilots vs betas), about getting the right people in the design room early, and about our experiences getting our first jobs out of college as well as the meandering path that led us all to Salesforce.

It was a great session and it got me thinking about sharing some fundamental product guidelines that I call the Salesforce Hacker way (in priority order because I'm a product manager and that's just how I roll):

  • Have faith. Not faith in the religious sense of the word but instead faith in yourself and your team. Otherwise, how will your ideas survive the dark night of other people telling you to work on other priorities first?
  • Figure out what's most important. When stack ranking ten stories, there's the first priority and then there's everything else. And whatever you choose, someone will tell you it is wrong. See rule one. Rob Woollen, former SVP of platform, gave this tip to me.
  • People over technology every time. Creating new products using new technologies like BigData for the Internet of Things use cases using Agile methodology with Full Stack developers may win you a game of engineering bingo. But if it doesn't solve real people's problems, what good is it? It's like a tree falling in the forest and no one being around to hear it.
  • Always be listening. Sales has their mantra, 'always be closing'. But for product, it's listening. Incidentally, when people say they are good listeners, they're talking, not listening. Listening is a skill everyone needs to develop; even those people who think they're good at it. 
  • Fail fast, fail often, fail spectacularly. Fear of failure blocks innovation. Learning from failure enables the next product to be better. Make sure your product organization supports your ability to fail as much as your ability to succeed. One of my best learning experiences came from a product that never launched leading to my next product being a success.
  • Complex designs lead to simple user experiences, simple designs lead to complex user experiences. How can you scope, constrain, and deliver the minimal amount of product necessary to trade customer value for feedback. The best feedback comes from less product, not more. I got this gem from the venerable Craig Villamor during a PTOn project a couple of years back. PTOn is where you take time out to work on a project that is not necessarily related to your current goals or team objectives.
  • Iterate, iterate, iterate. The longer a product stays in design or development, the bigger the chance of it never launching. Iterating enables a feedback loop from customers which will influence a roadmap of enhancements. 
  • Change takes courage. Designing and delivering a product may mean changing someone's concept of how things currently work. Treat that transition with respect and find ways to overcome the fear that comes with any change.
  • Stay calm, especially when everyone else isn't. This one is pure psychology. When stressed, our fight or flight reflex takes over. But what if there was a third option? When everyone else is stressed, a calm voice of reason can diffuse almost any situation.
  • You'd be amazed at what a smile and question can accomplish. Seems silly but keep in mind that everyone in the product lifecycle will protect resources, over estimate time or effort, and challenge ideas or priorities. These are actually good things to have in a product lifecycle. So keep smiling and don't be afraid to ask a clarifying question. My favorite starts with, 'why...?' and usually ends with, 'if you had this product, what would you actually do with it.' 
  • Transparency and honesty is critical. If your not willing to communicate via a banner trailing in the sky behind a plane, then you need to question what you're saying and to whom.
  • The size of an opportunity is directly proportional to the size of the problem. Keep looking for ways to disrupt people's mindsets and be ready to embrace it when it comes. 
  • Momentum is not the same as inertia. Never dismiss the power of momentum or how hard it is to start building a product. Never mistake inertia for forward progress. Products die sooner from inertia but get built with the right amount of momentum. 
  • Written specs are out of date as soon as the first person reads them. Requirements come from the tests and the documentation comes from the code. Everything else is a well articulated conversation between partners who have taken ownership of an idea.
  • Have Fun. Building product isn't easy but it is a lot of fun. If it's not fun, find a new job.
  • Come up with ten impossible ideas everyday. This exercise reminds me about possibilities in the face of compromise and even the basic laws of physics. This exercise actually originated in Alice in Wonderland.
I don't really expect anyone, including the students I met last week, to follow any of these guidelines. In some situations, I don't even follow all of them. That's why they're called guidelines.

It took me a long time to learn them through a set of experiences and challenges that culminated in successful products that I'm truly proud of. Many of these guidelines are inherited, borrowed, and stolen from the incredible people I work with on a daily basis. But if you work with product or aspire to build incredible products one day and you don't have any framework already, you might find some minimally viable goodness in these words. And from their, iterate, iterate, iterate.

That's the Salesforce Hacker way.

01 June 2015

Cloudlock Event Monitoring Viewer

Event Monitoring makes downloading log files easy using the Salesforce API. 







26 May 2015

Download Event Log Files Using the ELF Browser

Event Monitoring makes downloading application logs easy using the Salesforce API.











12 May 2015

Security Monitoring 101

Normally, when I get on the phone with a customer, they’re familiar with the audit capabilities within Salesforce and we just discuss the Event Monitoring add-on. However, while on the phone the other day with an IT security professional, I realized that we needed to take a step back and review the different options around auditing and monitoring user activity before we could dig into the add-on value of Event Monitoring.

This post is designed as a high-level introduction to security monitoring to better understand some of the different options security professionals have to audit data and user actions within their organization.

In general, the topic of auditing user behaviors in Salesforce can be summed up in just a few key features:

Audit Fields
Login History
Setup Audit Trail
Field History Tracking
Event Monitoring (Event Log Files)
Track who created or last modified a record by user and time
Track end-user logins and login attempts (e.g. failures)
Track administrative changes in setup like escalation of privileges or creation of new fields
Track state changes at the field level
Track a variety of server interactions including report exports, page views, and document downloads
Adam Torman modified the Acme account earlier today
Adam Torman logged in using Chrome v 42.0 on Mac OSX
Permission set Modify All Data: assigned to user Adam Torman
Adam Torman changed the Case status from Open to Closed
Adam Torman clicked on Marc Benioff’s patient record and downloaded the customer list
UI and API
UI (CSV Download) and API
UI Only
(CSV download)
UI and API
API Only (CSV download)
[Profile or Sharing] Permissions Required
* Read / Query requires sharing access to parent record
Manage Users permission
* View Setup and Configuration permission
Configure requires Customize Application permission

* Read / Query requires sharing access to parent record
* View Event Log Files permission
Data Retention Policy
Life of the record
6 months FIFO
6 months FIFO
Up to 10 years
Up to 30 days
$0 - 20 fields for 18 months

** $add-on - 60 fields for 10 years
$0 - Login/Logout lines for 1 day

** $add-on - 28 log files for 30 days
Online Help Documentation

* - View All Data will also enable access to everything but Login History
** - Talk with your account executive about the add-on price

Where do you go from here? There are great in-depth online documentation and best practices guides:
  1. Auditing documentation - high level overview
  2. Salesforce Security Implementation Guide - in depth best practices guide
  3. Salesforce Security Workbook - self-paced and interactive exercises
There are many more advanced features that help enable security professionals to audit user behavior and track activity.

Some additional solutions worth exploring in this area include:

Salesforce is a trusted cloud service. These solutions help you to trust but verify your user's behaviors.