How Trailblazer Identity (TBID) Works with Trailhead and myTrailhead

Almost weekly, I find myself trying to explain how Trailblazer Identity works with both Trailhead and myTrailhead.

For those that don’t know, Trailhead uses a service called Trailblazer Identity for managing user sign-up and login. Trailblazer Identity is one of the greatest innovations that Salesforce has created. It solves a truly unique problem set: how to unify all the Salesforce community properties such as Trailhead, Trailblazer Community, Dreamforce, Events, AppExchange under a common profile and identity that represents their single user across all Salesforce properties. At the same time, it also supports myTrailhead users within a company who may double up as Salesforce community users. That’s some serious double-thinking going on - you can be a member of several communities, plus access Trailhead, plus access private myTrailhead content - all as the same user! I could be an Independent Software Vendor (ISV) managing my app on AppExchange, a guest at Dreamforce, a partner attending a Trailblazer Community event, a Salesforce learner on Trailhead, or a learner on my own company’s myTrailhead tenant - all within the same day. That is a truly unique problem set that was solved with a single identity service!

Using Trailblazer Identity means a single person can use many different login identities (Google, Facebook, Salesforce, LinkedIn, Email) for many different use cases in many different user contexts (I’m an ISV, a partner, a learner, an admin, an employee, an event attendee) all going through the same identity service to sign up, login, access different types of content, and view their profile of accomplishments and engagement with Trailhead, myTrailhead, and the Salesforce community. As you can hopefully imagine, there are many different ways Trailblazer Identity interacts with users - whether it’s logging them in either via the web site or single sign-on, linking or merging their identities and users together, signing them up, or managing their settings including their hands-on orgs used for challenges. And it does all of this for both Trailhead and myTrailhead. As a result, there’s some complexity in the identity service which creates an opportunity to educate others how it works.

When I start explaining Trailblazer Identity in the context of both Trailhead and myTrailhead, I wind up with a white board that looks a little like this:

White board of Trailblazer Identity with Trailhead and myTrailhead

Keep in mind, every myTrailhead user is a Trailhead user. This means that myTrailhead users have full access as first class citizens to public Trailhead content while, at the same time, having access to their organization’s private myTrailhead content.

In its most basic form, Trailblazer Identity works like this: a new user signs up for Trailhead using a login identity that Trailblazer Identity accepts including:

• *Salesforce production org 
• including developer edition and a trial org
• Google
• LinkedIn 
• Facebook 
• Email
• email address/one-time password

*Important Note: sandbox org logins do not work with Trailblazer Identity for login or sign up. This affects Trail Tracker sync later on in this blog post. If you have developers in a sandbox that aren’t already in a production Salesforce org, Trail Tracker won’t be able to load any of their badges. Those developers can still use a different login identity like Google or Facebook; however, their badges won’t sync with Trail Tracker.

Web login and sign up options

Now that Trailblazer Identity has some information about the login identity that you’re using to sign up, it asks for some simple information to finish the user registration. All users, including myTrailhead users, must self-register first as a Trailhead user. This guarantees a set of rights for all users based on the Terms of Service for Trailhead. For instance, an organization can inactivate a production user, removing their access to their private badges. But the organization can't take away access to a user's public badges as long as that user connected a separate, non-production org identity to their Trailhead user. Because everyone must self-register as Trailhead users, there is no way to auto-provision users on Trailblazer Identity such as through an LDAP or Active Directory service.

Progressive Profile User Registration

So the whole login and signup flow looks a little like this on the white board:

Login and Signup flows put together

Keep in mind, the idea is to have a common user across all Salesforce properties based on the user’s email address. If Trailblazer Identity finds that the user already exists with the same email address that you just used to sign-up a new user, then it’ll link the new user with the existing one. This helps keep a user from signing up multiple times and losing track which user or login maps to which badges that they’ve earned.

If your intention is to create multiple Trailhead users intentionally, for instance if you’re getting ready to do a demonstration to your team but don’t want it to affect your real badges or profile, then you can use a different email address or modify your email. For example, Gmail allows you to add a ‘+’ in your address as a filter which will act like a new email address even if emails will still go to your original address. There’s a great blog from Google about using filters in email addresses.

It’s also important to understand that you can use more than one login identity tied to your Trailhead user, so any of the following login identities can be used to login to your single Trailhead User.

Multiple Logins, Only one of You

That means you can login to Trailhead one day with your Google login identity, the next with your LinkedIn login identity, another day with your Email using a one-time password, and another day using your Salesforce production org user. Logins just tell Trailblazer Identity how to map to the single user they’re associated with. You can also manage all of these login identities under the Settings page within Trailhead, choosing which ones to keep and which ones to disconnect or merge and link.

Manage Login Identities under Settings

Notice that ‘Connect’ button in the last picture? That helps Trailhead to link or merge login identities and even other existing Trailhead users with our user. This is because it’s possible that there are multiple Trailhead users with different email addresses even though in reality, there’s only one of you. If that is the case, you can link or merge them:

Linking or Merging users

The difference between link or merging users is that if the second Trailhead user has any badges, we’ll merge them into the first user before we combine all of their login identities together. Otherwise, Trailhead will just link their login identities to their one-and-only-one Trailhead user.

And now that you have your single Trailhead user, you can login through the web site by clicking the login button or through single sign-on. To learn more about the single sign-on route, check out this awesome blog post.

Most importantly, now that you have a single user with multiple login identities, you have a single place to share your user’s profile and accomplishments. It doesn’t matter what login identity you use to login, you can access your single Trailhead profile.

Public Trailhead Badges and Rank

However, if you login with your myTrailhead production org identity, you'll see something slightly different than if you logged in with any of your other login identities. You’ll see both your public Trailhead badges as well as your myTrailhead badges together. And your rank will be based on the combination of both public and private content instead of when you logged in using a non-myTrailhead org login identity where you only saw your rank in the context of public Trailhead badges and points.

myTrailhead + Public Trailhead Badges and Rank

This may cause your head to spin a little bit. I don’t blame you. One minute you’re a Mountaineer rank and the next you’re a Ranger! The advantage is whether you’re an administrator or developer earning public Trailhead badges, or an employee, end-user, partner or anyone else earning private myTrailhead badges. Your login identity helps establish the context of what you can see including your badges.

People find Trailhead through a variety of means such as searching Google, following someone on Twitter, and word of mouth. Most of these result in a new Trailhead user signing up via the public Trailhead web site.

A myTrailhead user will typically become a Trailhead user by clicking through a single sign-on deep link in an email inviting them to earn a badge on myTrailhead. They might also click a single sign-on link from another website like a community or within a chatter post in the Salesforce app.  Keep in mind, a Trailhead user must use a Salesforce production org login to access their myTrailhead content - that’s how Trailhead connects the dots between the org they’re logging in from and the myTrailhead tenant they should have access to. After all, it’s possible for a single Trailhead user to have access to multiple myTrailhead tenants of content.  If that user already exists and has logged into their production org in another browser tab, Trailhead will log them in automatically. If not, Trailhead will take them through the progressive profile sign up process and then deep link them to the content from the email.

myTrailhead login and single sign-on flow

And when they’re done with the content, if they logout from myTrailhead, they’ll be logged out from Trailhead as well and be directed to the Trailhead home page.

Finally, Trailblazer Identity helps Trailhead to connect the dots with Trail Tracker reporting. Trail Tracker is a free AppExchange app for tracking user badge and Trailmix activity. When reporting on badge activity via Trail Tracker, Trailhead uses your user’s information to decide how to sync their activity with their reporting organization.

Every day, a scheduled Apex job in Trail Tracker runs, it calls into Trailhead with the organization Id and retrieves all of the badge and Trailmix activity for any user who has linked or used the same production org identity to login for their Trailhead user.  That way, Trailhead can share the user’s public and private myTrailhead badges the same way Trailhead figures out whether you can see public or public and private badges on your profile. And if the user doesn’t use myTrailhead, that’s okay. Trail Tracker will sync all of their public badges with your organization - as long as they’ve linked at least one of their Trailhead user login identities with the same org. More about using Trail Tracker and linking login identities in this fantastic blog post.

Trail Tracker and User Identities

One use case that is a bit more challenging with Trail Tracker is using sandbox to test it. Trail Tracker actually does work in a sandbox, but the integration user has to be a production org user when you set it up since sandbox users can’t login to Trailhead to begin with. In other words, you can’t have developers who exist only in a sandbox org sync their badges with Trail Tracker running in sandbox since it's not possible for them to login to Trailhead in the first place to earn badges. This isn’t a limitation in Trail Tracker - it’s just the way Trailblazer Identity works - since you can’t login or sign up with a sandbox user, you can’t earn badges and if you can’t earn badges, you can’t sync them to Trail Tracker. Access is based on the link between a Trailhead user’s production org identity and the production org where Trail Tracker is installed.

Trailblazer Identity is one of the greatest innovations that Salesforce has created. It allows you to access multiple communities in different contexts as your day switches you from partner, to customer, to developer, to employee end-user. It solves many difficult problems and helps us unify the community as well as providing a secure, scalable, and trusted service for all Salesforce community properties including Trailhead and myTrailhead.

Using Single Sign-on with Trailhead

In March, Trailhead introduced a new identity service called Trailblazer ID (TBID). This innovation enables Salesforce to create a foundation for unifying community properties such as Trailhead and the Trailblazer Community. But under the covers, there are a number of incredible innovations, one of which I'm asked about at least once per week -

"Can I single sign-on (SSO) and deep link to content on Trailhead without having my users login to Salesforce first and navigate through the site?" 

The short answer is, YES!

There is one important caveat, of the four login types including Salesforce, Google, LinkedIn, and Email, this solution will only work with your Salesforce login.

Trailblazer ID Login Options

As a result, you need to link your Trailhead account using a Salesforce org login to make SSO work. This is because it gives TBID enough information about who you are to log you in correctly using our SSO solution.

The following excerpt is customized from the myTrailhead Help & Training docs (I can't take credit for that writing - the myTrailhead doc writer deserves all the credit) that describes how to create an SSO deep link to content on myTrailhead. However, with one small change described in this blog post, it works for Trailhead as well.

myTrailhead Help & Training Docs

The second section of this blog post describes how you can apply that deep link using a simple formula customization built on top of Trail Tracker to make it 'button click' easy to access content on Trailhead as a logged in user.

Let's say you work at the Pacifica company, and you want to single sign-on an Administrator to the Advanced Formulas module on Trailhead. You can build a link that initiates the necessary relays to confirm that a user is authenticated and then takes the user to the module.

For example, this SSO link leads to the Advanced Formulas module on Trailhead.

https://trailblazer.me/relay?community=trailhead&mydomain=pacificalearning&path=/content/learn/modules/advanced_formulas/

Follow this process to build the link.

Navigate to the Trailhead content that you want to link to, such as the Advanced Formulas module.

Keep the page open in a browser so that you can refer to it. The URL contains some of the details required to create the SSO link.

Example: https://trailhead.salesforce.com/content/learn/modules/advanced_formulas/

Advanced Formulas Module - Logged In User

This URL contains the following information for building an SSO link.

Trailblazer ID Community—trailhead
Namespace name—learn
Content type—modules
Content API name—advanced_formulas
Name the online location of the relay service—trailblazer.me

Example: https://trailblazer.me

Add the relay prompt that initiates SSO authentication: /relay?.

Example: https://trailblazer.me/relay?

Now tell the relay where to go by adding community=trailhead.

Example: https://trailblazer.me/relay?community=trailhead

Add an ampersand (&) and one of the following, depending on whether My Domain is set up in your Salesforce org.

If My Domain is set up in your Salesforce org, add mydomain= and your My Domain name, such as pacificalearning.

If My Domain is not set up in your Salesforce org, add instance= and the instance where your Salesforce org is located, such as na57.

Example:

With My Domain:

https://trailblazer.me/relay?community=trailhead&mydomain=pacificalearning

Without My Domain:

https://trailblazer.me/relay?community=trailhead&instance=na57

NOTE To determine if My Domain is set up in your Salesforce org, navigate to Setup > My Domain. If your org uses My Domain, the domain name is on that page. To determine the instance where your Salesforce org is located, in your org, navigate to Setup > Company Information.
You’ve built the part of the link that confirms whether the user is authenticated through SSO. Now add the path to the content where you want to take your users.

Add &path=/content/.

Example:

With My Domain:

https://trailblazer.me/relay?community=trailhead&mydomain=pacificalearning&path=/content/

Without My Domain:

https://trailblazer.me/relay?community=trailhead&instance=na57&path=/content/

To add the path to the content, refer to the URL that you navigated to in step 1. Add:
The content type, such as modules/ or trails/.
Your namespace name, such as pacificalearning/
The content API name, such as advanced_formulas

Example:

With My Domain:

https://trailblazer.me/relay?community=trailhead&mydomain=pacificalearning&path=/content/learn/modules/advanced_formulas/

Without My Domain:

https://trailblazer.me/relay?community=trailhead&instance=na57&path=/content/learn/modules/advanced_formulas/

Now you’ve created the SSO authentication link that you can send to your users!

But how would you use this in the real world?

You could use this to generate links using an Excel formula and sending the links out via branded emails as invitations to complete Trailhead badges. The downside of this solution is that if you haven't logged into your organization yet, you'll have to first login since we don't have enough information from your email alone to log you into Trailhead.

Another way you could auto-generate these SSO deep links to Trailhead content is to build a formula field in your org with Trail Tracker. I like this approach over email because it guarantees that you're already logged into your Salesforce organization.

Button Click using Single Sign-on to a Trailhead Module

The flow is pretty straight forward: when you view a badge record, you can click on a custom field, in this case called Single Sign-on URL, it will login you into Trailhead automatically and navigate to the Advanced Formulas module. And if you haven't already registered as a Trailhead user, don't worry, TBID will take you through the progressive profile to create a new user and then return you to the Advanced Formulas module when you're done.

To create the field, you just need to go to Setup as an Administrator and under the Badge object, create a new formula field called Single Sign-on URL.

Badge Formula Field

The following formula is a starting point for trying this out in your org. It checks the type of badge (If Module, Then Project, Then Superbadge, Else "None") and then constructs the SSO URL by parsing the standard trailheadapp__URL__c field that comes with the Trail Tracker App.

Formula:

IF (ISPICKVAL(trailheadapp__Type__c, 'Module'), HYPERLINK('https://trailblazer.me/relay?community=trailhead&mydomain=pacificalearning&path=/content/learn/modules/'&IF(BEGINS( trailheadapp__URL__c , "https://"), MID( trailheadapp__URL__c , FIND('https://',  trailheadapp__URL__c , 1)+50, (LEN( trailheadapp__URL__c ) - FIND('https://',  trailheadapp__URL__c , 1)+50)),  trailheadapp__URL__c  ),  Name  , '_blank'),IF (ISPICKVAL(trailheadapp__Type__c, 'Project'), HYPERLINK('https://trailblazer.me/relay?community=trailhead&mydomain=pacificalearning&path=/content/learn/projects/'&IF(BEGINS( trailheadapp__URL__c , "https://"), MID( trailheadapp__URL__c , FIND('https://',  trailheadapp__URL__c , 1)+50, (LEN( trailheadapp__URL__c ) - FIND('https://',  trailheadapp__URL__c , 1)+50)),  trailheadapp__URL__c  ),  Name  , '_blank'),IF (ISPICKVAL(trailheadapp__Type__c, 'Superbadge'), HYPERLINK('https://trailblazer.me/relay?community=trailhead&mydomain=pacificalearning&path=/content/learn/superbadges/'&IF(BEGINS( trailheadapp__URL__c , "https://"), MID( trailheadapp__URL__c , FIND('https://',  trailheadapp__URL__c , 1)+56, (LEN( trailheadapp__URL__c ) - FIND('https://',  trailheadapp__URL__c , 1)+56)),  trailheadapp__URL__c  ),  Name  , '_blank'), "none")))

That's the power of the Salesforce platform. From there, you can introduce this link in Login Flows, Workflows, Notifications, Reports, and pretty much anywhere the formula can be presented to a user.

Single Sign-on to Trailhead from your Salesforce organization is possible to help you ramp your team on Salesforce.

Getting Badgy at a Trailhead Badge-a-thon

I had an incredible conversation at TrailheaDX ‘18 with Mark Korf. During that conversation, we discussed a really interesting problem - how do you report on badges at a Trailhead badge-a-thon?

At this point, you’re probably asking yourself, ‘I’ve heard of a hack-a-thon, but what’s a badge-a-thon?!’

A badge-a-thon is an event where you bring together trailblazers who compete to earn badges. Those people who win the badge-a-thon earn prizes like cool swag.

But the best part of the badge-a-thon is that it brings Trailblazers together using Trailhead, the fun way to learn Salesforce. Badge-a-thons introduce trailblazers to career opportunities by learning about Salesforce while keeping it fun and engaging.

We had one badge-a-thon last month where over ten thousand badges were earned!

What Mark wanted to do was host badge-a-thons at user groups and with schools to open career opportunities and enable trailblazers to do their jobs more effectively, all while they were having fun and winning swag.

In order to award the swag, Mark needed to track who earned the most badges. Enter Trail Tracker from the AppExchange.

Integrating the Trailhead Profile into an org for tracking badge activity

Trail Tracker is a free app on the AppExchange that enables you to guide your trailblazers through their Salesforce learning adventure on Trailhead. Assign, track, and report on badges earned by your team via pre-built reports and dashboards to take your Salesforce game to the next level.

Free AppExchange App

Trail Tracker was originally intended to enable the tracking of employees badges. Mark didn’t have employees, he had user groups and student trailblazers. This presented a different problem. How do you bring individuals together, many of whom were already in their own production orgs, for the purpose of tracking their badges during the event?

How to set up Trail Tracker for a Trailhead Badge-a-thon

1. Sign up for a Developer Edition org: https://developer.salesforce.com/signup

You need someplace to track the results. Developer Edition is a free org you can use to try out things. And while you can use an existing org like production, you’re going to be adding non-production users so it’s better to keep it separate.

Sign up page

2. Install Trail Tracker into the new org: https://sfdc.co/trailtracker

Just head to the AppExchange and install Trail Tracker in your newly provisioned Developer Edition Org. It’s a good idea to have the installation directions and the FAQ standing by in case you need it.

Trail Tracker installed in Developer Edition Org

3. Add badge-a-thon participants as new Chatter Free Users

Besides being free, Developer Edition also provides 5000 Chatter Free licenses which enables you to host a badge-a-thon up to that number easily.

5000 Chatter Free Licenses

Keep in mind, Chatter Free licenses don’t have any access to object data in an org in case you're concerned about those users accessing data that they shouldn't.

Create a new Chatter Free user for each badge-a-thon participant

4. Configure Trail Tracker

Configuring Trail Tracker may be a little challenging as many integrations tend to be. I highly recommend having the installation directions handy for this part.

When you configure Trail Tracker, make sure to select at least the Chatter Free license type as well as Standard.

Trailhead Setup

Configure the sync to run at the end of your event so you can do the final tally. The sync currently runs once per day.

Sync Settings

5. Have your new badge-a-thon users login for the first time

You want your newly minted Chatter Free users to login and change their password. They’ll need the password for the next part.

If the user has never logged into Trailhead before, they can just go directly to sign up and start earning badges. Since they’re logging in using the Chatter Free user you provisioned for them, their badges will automatically start flowing into your Developer Edition org every time Trail Tracker syncs. However, if your users already have Trailhead users established, you'll need to follow a slightly different path.

6. Link/merge Trailhead User Accounts for Existing Trailhead Users

This is conceptually the most interesting part of the entire solution.

The way Trailhead works, each user earns badges. But each user may use multiple identities to login to view their badges.

Some users already have a Trailhead login and don’t want to give up their badges. The good news is that they don’t have to. They can link or merge their accounts.

You can read more about linking and merging from the knowledge base article: https://force.desk.com/customer/en/portal/articles/2896953-trailhead-self-service-account-merge?b_id=13477.

The decision to link or merge comes down to one thing - is there already an existing Trailhead user with badges or is this a new identity that you’re going to use to login to your existing Trailhead user?

If it’s the latter, you’ll just need to link the two.

Have your users login to Trailhead using their normal login and go to settings.

Trailhead Settings

Under settings, have them go to the Salesforce Login section and click the ‘Connect or Merge’ button.

Connect or Merge

Login using your newly provisioned Chatter Free user from the badge-a-thon org. You’ll be prompted to login and allow access.

Allow access

Then you’ll be prompted to link accounts.

Link Account

Once linked, you can go back to Trailhead where you’ll see your newly linked login under the settings page for your existing Trailhead user and you're user is ready to go. Any badges they earn, regardless of whether they login using their existing identity or the newly created Chatter Free identity, will be added to the single Trailhead user that you can report on.

Salesforce Linked Accounts

However, if you have overachievers who have already signed up for Trailhead using their badge-a-thon Chatter Free users and started to earn badges, you’ll need to have them merge accounts with their existing user. Don’t worry, no badges will get lost in the process and they never lose access to their Trailhead user.

Have those users login to their existing Trailhead user account and go to settings. They should click the ‘Connect or Merge’ button and login using the badge-a-thon Chatter Free user that also has badges. They’ll be prompted to merge their accounts an provided with all the information about what badges and points will go once the merge is complete.

It’s merging time!

Then comes the scary screen - ‘the merge is irreversible’ - Are you sure? Of course you are!

Are you sure?!

After the merge, you’ll see the results.

Merge Results

And now you can login using either your existing Trailhead user’s identity or the newly provisioned badge-a-thon Chatter Free user that was provisioned for you. Once again, our single Trailhead user may have multiple identities that they use to login in order to earn badges.

Salesforce Login

And when those users earn badges against their single Trailhead user, they’ll be sharing them with the badge-a-thon org based on the affinity to the Chatter Free user identity that they've linked to.

After the badge-a-thon, or at any point, your users can remove the Chatter Free identity from settings by clicking the big ‘X’ under the Actions menu next to the identity that shouldn’t be used any longer. That will opt them out of sharing the badge data with the badge-a-thon org and will prevent that Chatter Free identity from being used to login to their Trailhead user. That way, your users can choose whether to opt-in or opt-out from sharing badge data, all without ever losing any badges in the process.

6. Track badges in Trail Tracker

Finally, you’re ready for the big day. Your trailblazers can now start earning badges. And when you login to your badge-a-thon org with Trail Tracker, you can navigate to the app to track the activity.

App Menu

Just go to Dashboards and click on the Trailhead Overview.

Dashboards Tab

Trailhead Overview Dashboard

You can customize the dashboard as you need and run reports that help you understand what badges are being earned by which badge-a-thon users.

8. Award prizes

The day of the badge-a-thon is finally here! Time for your users to start learning and winning some cool prizes.

My kingdom for a hoodie!

Don't worry about copying down all of these steps, they're all available on the following trailmix if you want to track them: https://trailhead.salesforce.com/en/users/005500000060MZlAAM/trailmixes/getting-badgy.

Thanks Mark for the great use case!!

What's new in Spring'18 with Event Monitoring

Summary of Event Monitoring Spring'18 Release Features

1. Hourly Event Log Files Beta - enhanced interval to obtain event log data for customers and partners

Currently EventLogFile object has your Salesforce event data from the previous 24 hrs. With hourly event logs you are able to track events that have been generated 2-4 hrs ago alongside daily event log files. See the interval field from the picture below where Interval = 'hourly' from workbench API tool. 

This allows you to make decisions whether you pull your event log files several times a day to your analytics environment for security or performance monitoring use cases or stay in the daily batch for adoption monitoring. The hourly event log files does not automatically work with event monitoring analytics app, Splunk, New Relic, FairWarning or Cloudlock. Please work with your analytics team to start using the hourly files. 

Link to release notes.

2. Insecure External Assets Event Log - track insecure external assets hosted in Salesforce and fix URLs from HTTP to HTTPS. This event log file will be generated when your users are accessing external assets like images in Salesforce over insecure HTTP protocol. The insecure external assets event log file will be provided free of charge and out of box to all customers similar to Login and Logout event log files. 

Link to release notes.

3. Delete Event Log Files - to help comply with existing and upcoming data regulations like GDPR, event log data can now be deleted with a specific Delete Event Monitoring Records permissions. 

Before this permission can be assigned to a user or permission set, there is also a Org wide preference that needs to be turned on. 

Link to release notes.

4. Track User Actions with time based workflows - correlate multiple events together with Login Key and Session Key

To get more visibility into Time Based Workflow, we've added the Login and Session Key to help track all transaction changes in the specific Time Based Workflow.

Link to release notes.

5. Salesforce Connect Event Log enhancements - track external objects comprehensively

For Salesforce Connect customers, several log files enhancements have been added to provide more fine grain visibility for external objects, be it query or write operation, when the call occurred and which user accessed the data.

• External Cross-Org Callout events
  • EXECUTE_MS—How long it took in milliseconds for Salesforce to prepare and execute the query. Previously, this field was reserved for future use.
  • FETCH_MS—How long it took in milliseconds to retrieve the query results from the external system. Previously, this field was reserved for future use.
  • ROWS_FETCHED—(New) Reserved for future use.
• External Custom Apex Callout events
  • EXECUTE_MS—How long it took in milliseconds for Salesforce to prepare and execute the query. Previously, this field was reserved for future use.
  • FETCH_MS—How long it took in milliseconds to retrieve the query results from the external system. Previously, this field was reserved for future use.
  • ROWS_FETCHED—(New) Number of rows fetched by the callout.
  • THROUGPUT—Number of records retrieved in 1 second. Previously, this field was reserved for future use.
• External OData Callout events
  • EXECUTE_MS—How long it took in milliseconds for Salesforce to prepare and execute the query. Previously, this field was reserved for future use.
  • FETCH_MS—How long it took in milliseconds to retrieve the query results from the external system. Previously, this field was reserved for future use.
  • NEXT_LINK—OData next link that the callout used to request a subsequent batch or page of rows. Previously, this field was reserved for future use. This field isn’t supported for the OData 2.0 adapter on orgs created before Spring ’18.
  • PARENT_CALLOUT—If the callout requested a subsequent page of rows, this field identifies the initial callout whose request resulted in the multi-page result set. Previously, this field was reserved for future use. This field isn’t supported for the OData 2.0 adapter on orgs created before Spring ’18.
  • ROWS—Total number of records in the result set. Previously, this field was reserved for future use.
  • ROWS_FETCHED—Number of rows fetched by the callout. Previously, this field was reserved for future use. This field isn’t supported for the OData 2.0 adapter on orgs created before Spring ’18.
  • THROUGHPUT—Number of records retrieved in 1 second. Previously, this field was reserved for future use. This field isn’t supported for the OData 2.0 adapter on orgs created before Spring ’18.

Example

Suppose your Salesforce org connects to an external system via an OData adapter. When you defined the external data source in Salesforce, you selected Named Principal for Identity Type. With the named principal, the same set of credentials is always used to access the external system from your org.

To identify the users who accessed an external object’s records during a specific time period, use the log data for the External OData Callout event type. Sort by ENTITY and USER_ID to see which users accessed the external object.

In this event log file, we see that three users accessed the Product external object over 12 callouts.

Link to release notes.

6. Event Monitoring Analytics App Trailhead, in case you're using the Event Monitoring Analytics App or a new customer getting started the Event Monitoring Analytics App Trailhead is a great way to spend 1h 15 mins to understand how to get started for adoption, performance or security monitoring for your Salesforce application.

7. Changes to Event Log File schema due to regulatory consistency

Document Attachment Downloads event log file

We retired the FILE_NAME field. If you’ve created custom fields and need to retrieve data from the FILE_NAME field, query the Document standard object. For example, SELECT Name FROM Document WHERE Id=[ENTITY_ID value from Document Attachment Downloads log data].

Knowledge Article View event log file

We retired the USERNAME field.

Logout event log file

We retired the USER_NAME field.

Link to release note of changed objects

Event Monitoring at Dreamforce 2017

Ready for Dreamforce 2017? 

Wanted to give a quick list of Salesforce Shield & Event Monitoring related break out sessions that might be worth your time to check out:

What: How to Use Event Monitoring to Drive Adoption and Performance
Where: Moscone West 2024
When: 11/6/2017 at 9:00-10:00am

What: Getting Started with Event Monitoring and Field Audit Trail
Where: Moscone West 2008
When: 11/7/2017 at 1:30-2:10pm

What: GDPR Game Show
Where: Moscone West 2024
When: 11/7/2017 at 3:00-3:40pm

Have a great Dreamforce! 

#DF17

How to Customize Your Report Downloads Dashboard

Attention all security folks! How to monitor data exports from cloud applications is always popular topic amongst security teams.

With Event Monitoring and Salesforce Shield, customers can closely follow these activities in form of Event Log Files and Transaction Security Policies. With Event Monitoring Wave App, customers can further visualize who's downloading data (exporting reports).

Event Monitoring Wave App already includes the out of the box denormalization from UserIDs to Usernames but with three simple steps you can also denormalize and update your Report Downloads dashboard to include what reports your users are downloading.

Dennis Schultz, Principal Solution Engineer from Salesforce has worked on a short video that shows how to use Salesforce Wave Analytics Recipe feature to bring more Salesforce data into Wave and transform your dashboards to include Report Names just under 5 minutes.

How to add Report Names to the Report Dashboards with Salesforce Wave Analytics Recipes in 3 easy steps.


1. Create "Lookup" Dataset

• From your Wave app environment click Create Dataset. 
• Select Salesforce as the source and select Report object. Select fields e.g. Report ID and Report Name. Create the Dataset. 
• To enable the integration between Wave Analytics and Salesforce, go to Data Manager to enable the default Salesforce Dataflow. Once finished, soon you'll see the dataset in your Wave environment. 
• You can confirm you have the right information from the Values table.

2. Create a new Report Export Dataset with Recipe features

• Go to Data Manager and select Prepare
• Create Recipe and Select ReportExportWithUsers Dataset as the base to work with
• Name your new Dataset "ReportExportWithReportNames"
• Transform the table with the Lookup Dataset we created in Step 1 with Add Data Transform
• Select URI_ID_Derived from the Base ReportExportWithUsers Dataset and Report ID from the new Lookup Dataset
• Now specify you want the Report Name field to be included in the new Dataset
• Finally create Dataset to run the Recipe
• Run on scheduled to pick up new events daily

3. Update the Report Downloads Dashboards

• Open the Report Downloads Dashboard
• Make a Copy or Clone the Dashboard before continuing 
• Rename the Dashboard "New Report Downloads" and Save
• Open ReportExportwithReportNames DataSet
• Group by Username and ReportName - some names might not be available e.g. User created a new report and deleted the report
• Click the scissors to "Clip to Designer" the lense and Provide a name ReportExportWithNames 
• Return to the New Report Downloads Dashboard and hold the Shift Key down and move the widget to the Dashboard
• Save the Dashboard and Click the Eye button to view it

Please take a look at the video and leave comments or questions below: http://salesforce.vidyard.com/watch/SfuJDkrD9qmycyjgwcdiNS

Cheers, Jari

Augmenting Salesforce Event Monitoring Datasets

Augmenting Salesforce Event Monitoring Datasets in Wave Analytics to understand in more detail what records your users have been viewing

In this short video Dennis Schultz, Principal Solution Engineer at Salesforce describes how you can use Event Monitoring for Adoption, Performance and Security analysis and specifically use the URI (PageView) dataset in the Event Monitoring Wave App with Wave's new Recipe capability (in Spring'17) augmented with entity type, turning the data set and visualization into more insightful and easier to use for human analyst consumption.

To enable your Event Monitoring Wave App, please visit the instructions in Salesforce Help & Training or to have Event Monitoring turned on to your Salesforce application, please get in touch with your Account Executive.

To get more familiar with Wave Analytics, see the these Trailheads training modules and to learn more about Salesforce Shield and Event Monitoring please capture these badges.

Please leave your questions and comments below! 

Cheers, Jari

Creating Custom Event Monitoring Wave Dashboards

Creating Custom Event Monitoring Wave Dashboards

Are you a Salesforce Shield or Event Monitoring customer using the Event Monitoring Wave App? Do you know it's pretty easy and - also very quick - to create custom views to the Event Monitoring data?

Mike Smith, Salesforce App Cloud Solution Engineer based in Denver, Colorado area is an expert with Event Monitoring and in this short video below Mike will demonstrate how quickly you can create a custom dashboard with Event Monitoring Wave App for Logins in the last 7 days.

Enjoy!

10 Event Monitoring Gifts for the Holidays

Guest post by Arastun "Russ" Efendiyev. Arastun is Lead Solution Engineer for the Salesforce Platform based in Greater Boston Area. He works with many Salesforce Shield and Event Monitoring customers and is one of the leading experts for Salesforce Event Monitoring and Transaction Security. You can connect with Russ on LinkedIn and follow him on Twitter.

10 Event Monitoring Gifts for the Holidays

Holidays are around the corner, and odds are that you’re finding yourself with a shopping list for all the gifts. But don’t forget reward yourself! If you have Event Monitoring, here are Ten Best Practices you can take advantage of - put them on your list!

For those of you unaware of Event Monitoring, here is a quick cheat-sheet to get you up to speed.

Here are the Ten Best Practices.

1. Sit Down and Define what you want to track. Have a Monday morning meeting about it. Take the Event Monitoring reference API doc that provides a list of all things you can track for each event. Ask yourself “What would the ideal dashboard look like?” Use the API doc to help you understand all the data points you can track. Maybe some of them exist outside of Event Logs (i.e., metadata/config changes) – that’s okay, throw them onto the dashboard. Too often I see folks zero in on the technology and encounter a ‘technology-first, business-second’ dilemma. Reverse it! Just bring some good donuts to the meeting.

2. Offload. The logs are retained in Salesforce for 30 days. Then they leave. Set up a process to export them on an archive of your choice. A large use-case of Event Monitoring is doing a retroactive forensic analysis on an individual or individuals that left the company. Let’s say the individual took down top Contacts in a report export and went to a competitor. They did it 4 months ago. You have to be prepared to be able to mine that data. Set up automation – such as using shell scripts provided here and running a scheduled cron job to grab data, or scheduled to run this python script provided here. A SIEM tool can help with this and eventually have data reside after it leaves Salesforce in 30 days. This is especially helpful as various SIEM tools excel at log-aggregation and ingestion, which comes from Event Monitoring files. Contact us and we can provide some SIEM vendors that have hot-pluggable adapters for Event Monitoring, if you want an out-of-the-box experience.

3. Compliance vs Productivity. It’s definitely something we all live and breathe, especially in Financial Services, where I see a lot of companies try to walk this very fine and very important line. Use a security model that’s too strict and your end users don’t use the system, while security that’s too lax comes with more threats. Let’s use the same example. So you’re still worried about someone leaving for a competitor and taking all your reports? Okay, remove their privilege to Export Reports and their decommission Connected App Data Loader access. Problem solved, right? Whoops. Too bad you just prevented the user from working on various things they’d need to do in Excel with the exported data. No worries here – Transaction Security, a feature of Event Monitoring that can alert/block on events in real time, can help. It lets you provide a granular scope on certain types of records and how their export will happen. Maybe we only block anyone who exports an entire contact list, or over 100 contacts. Or, even more lax, maybe we let them do it but email an alert saying they’ve done it. Or, only email or block if they did it in off hours for over 100 contacts. Or email if they did it in off hours, their profile was Standard User, and their User object had a Suspicious__c checkbox boolean flag turned on. You can get really flexible here and get much closer to the business, while letting the end users be productive

4. Keep up with our roadmap! We release 3X per year. Obligatory Forward-Facing statement / #Safeharbor here. We have product managers mapped to Event Monitoring functionality, the Transaction Security aspect of it, and even our Wave Admin Analytics for Event Monitoring visualization. Take a look at a recent Winter ’17 example of some things we put in Transaction Security. To broaden picture: we executed on Transaction Security and Wave Admin Analytics – and those are undergoing iterations. Part of it is feedback from YOU! What are the use-cases that are important to you? Continue to share wiith us and we’re open to putting them in our roadmap.

5. Data can come from elsewhere. Event Monitoring is the end-all-be-all. What about your authentication history? Your metadata/configuration changes? Your data & field history changes? Easy to overlook. Don’t forget them for your next audit. As per its name Event Monitoring provides insights on events, while data/metadata changes are a great complement. Wear your fancy audit shoes, seamlessly crunch out reports on all of these things, and give them to the auditors.

6. Join your friend objects. Okay, so you have your logs. Let’s take a look at that example of ours – a user extracting a report. They collect information on User ID of 00530000009M943. Good start, but we need to make sense out of it. Well, we have User Object. Plug that into your reporting solution on Event Monitoring, whether it’s a SIEM or our Wave App, for 30 days worth of retention. If I’m looking at a report, Report ID is captured, which can be joined against the Report table to give it a name (versus an ID). We now find out that it was John Smith that looked at a Top Contacts report. And if I want to get a Profile mapping to it, I know that Profile is tied to User via User’s ProfileId. The Wave Admin Analytics is effective here since we’ve brought over some of these friendly objects!

7. QA Buddy. Not everyone has a QA team and/or QA automation, like Selenium, within their enterprise. When you test your Authorization model, Login-As is a great feature (which is trackable on Event Monitoring, by the way). It lets you impersonate an end-user so you can validate that they can or can’t see functionality, especially data. Who can or can’t see data, create it, edit/update it, etc. Login-As is a QA process, whether it’s you doing it or another individual checking your work. Here’s where your thoughtful effort on Profiles, Permission Sets, Criteria Based Sharing Rules, Apex Managed Sharing Rules, Org Wide Defaults, Role Hierarchy, etc. is put to the test. Those are very important controls – we don’t want the wrong individual within the org to see wrong data, let alone act on it. With event monitoring, you have a true validation of the controls you put in place. You can assert that John Smith never saw a Case filed by Bob Jones for Payroll to validate Bob’s paycheck amount reflects the hours worked. Or, you finally saw that John was able to look at John’s payroll case. So you know your controls need to be changed. This is true automation to validate your controls.

8. Insights into Usage. As per above example of John looking at Cases, you may find this insight beneficial beyond security validation. Let’s say that you want to see how much your Sales team, that John Smith is part of, is looking at customer-only Cases – you’re trying to understand if they are able to help the customer and/or even find new product line opportunities. Event monitoring can help track both use cases, being your QA Buddy for the authorization model and seeing how much functionality is being utilized. A Sales individual can look up a Case and give the customer a call. If they don’t have Salesforce integrated to Telephony, there may not be anything tied to that record, but the log will remain that John Smith went on a customer-field case eight times in two days!

9. Trailhead! We have released various Trailhead modules to get hands-on with this and we run a checker to see if you got your work right or wrong in your Developer org, an account where you can test this. Here are some Trailhead modules: Transaction Security Trailhead & Event Monitoring Trailhead. There are many other modules that have Security – feel free to search for them in Trailhead depending on your security area of interest.

10. Optimize where it matters. So you saw your complex Visualforce page, that utilizes Angular and is backed by sophisticated Apex Controller, encounter a slower render/request time. You spent 14 hours fixing it. Success! Actually, the behavior witnessed was close enough to average request time. Remember, this was based off your perception of a slower request time. The kicker is that there are two other Visualforce pages that are behaving a good standard deviation out of the ordinary. Perhaps we should’ve chased after those! This is where Event Monitoring can go beyond security – it can help you justify which change requests/projects to allocate your time to. The next kicker is: You encountered slowness on your fancy Visualforce page that was behind or close to average request time… but did you know that you and your peer administrator/developer were the only ones using and testing it? Event Monitoring can tell you how much of your functionality is being used. So perhaps it’s those other two Visualforce page that have been utilized by a lot of users in the past few days that need tweaking!

Happy holidays. Leave your comments below or tweet and discuss with the #salesforcehacker hashtag! Many thanks also for Mike Jacobsen for his contribution on this blog.