đź“Ł Attention Salesforce Certified Trailblazers! Link your Trailhead and Webassessor accounts and maintain your credentials by December 14th. Learn more.

Get Started with Transaction Security

Flower icon used to indicate that the content is for Salesforce Classic

Attention, Trailblazer!

Salesforce has two different desktop user interfaces: Lightning Experience and Salesforce Classic. This module is designed for Salesforce Classic.

You can learn about switching between interfaces, enabling Lightning Experience, and more in the Lightning Experience Basics module here on Trailhead.

Learning Objectives



Be careful—Transaction Security is a powerful feature. An incorrect Login Event policy that blocks for its real-time action locks you out of your org. To prevent this from happening in an org you care about, create a new Trailhead Playground for this module. Yes, we really mean a brand new Trailhead Playground.

After completing this unit, you’ll be able to:
  • Describe the benefits of transaction security.
  • Explain what policies, actions, and notifications are.
  • State at least three use cases for transaction security.

What Is Transaction Security?

You’re the admin. You’re managing the Salesforce org. You’re juggling users, apps, objects, reports, and everything else. Now your manager asks you to make sure that no one is using an unsupported browser. Before you get started on that task, someone from IT asks you to make sure no one has a bunch of sessions active at once. What?! How are you supposed to watch for all those things on top of everything else?

The answer is, you don’t. Instead, you have Transaction Security watch for you.

“Transaction security” sounds like actions taken when selling things, but at Salesforce it means monitoring Salesforce events in real time to spot and correct trouble right away. You pick a transaction, or event, to watch for and then you choose what to do about that event. The rules and actions you create are called policies.


Using Transaction Security requires purchasing a Salesforce Shield or Salesforce Shield Event Monitoring add-on subscription.

For example, allowing users to have multiple login sessions can be a security risk. Let’s say someone starts work on a desktop computer, switches to a tablet, and then walks away from the desk. The desktop session is still active and open for anyone to use. To prevent users from having too many sessions active at once, you’d pick the login event and create a policy. For instance, you can state that if users already have three active sessions, they have to end one of the sessions before logging in to a new session. You can also include that you get notified when this event occurs.

So, Transaction Security is a feature that monitors Salesforce events in real time and applies actions and notifications based on rules you create. These rules, or policies, are applied against events in your org. (In the earlier example, our policy was to have no more than three active sessions per user.) You create policies for certain event combinations, and specify actions to take when those events occur.

Policies move through three states:
  • Available—Any policy you create, plus the example policies that Salesforce supplies. These policies are listed on the Salesforce Transaction Security Policies page.

    Transaction Security policies page showing the supplied policies.

  • Enabled—Available policies that the admin has “turned on,” shown by having Enabled checked. These policies are running and are also listed on the Transaction Security Policies page.
  • Triggered—A policy that’s been activated. This happens when the event the policy monitors not only occurs, but occurs in such a way that the event meets the policy’s requirements. Let’s consider the earlier login example. To trigger the policy, not only does the event have to be a login event, it also has to be for the user’s fourth active session.

For example, you can create a policy to take care of that request to block unsupported browsers mentioned earlier. Let’s say you don’t support Safari, so you set up a policy to watch for Safari users logging in. When someone does try to log in with Safari (and they will!), the policy is triggered and blocks the user. The policy also notifies you when it’s triggered, by sending you an email. You can have a policy that, when triggered, takes the action, notifies you, or takes action and lets you know about it.

You can set up all policies with the Transaction Security user interface. Here’s what our No Safari policy looks like when we set it up.

Transaction Security page for creating a new policy.

You might have noticed the Apex Policy field. We will be using Apex later, but don’t worry about that now. We’ve set the No Safari policy to automatically create the Apex class it needs—that’s what Generate Apex means in the Apex Policy field. You can also fine-tune a policy by changing its code. Yes, “code” is a four-letter word, but these changes are easy. We’ll get to those changes later after you’re more familiar with transaction security basics.

You’re probably wondering what items you can check for with Transaction Security. A transaction security policy consists of events, notifications, and actions.
  • The available event types are:
    • Data Export for Account, Case, Contact, Lead, and Opportunity objects. Prevents unauthorized downloads.
    • Entity for authentication providers and sessions, client browsers, and login IP. Provides notification when a specific resource (entity) is accessed.
    • Logins. Limits sessions or requires additional authentication.
    • Access Resource for connected apps and reports and dashboards. Blocks access to sensitive information or requires two-factor authentication before access is allowed.
  • Policy notifications are sent to the selected admin using:
    • Email
    • In-app notification to your Salesforce app
    • Both email and in-app notifications
    • No notifications (notifications are optional)
  • If the policy is triggered, you can:
    • Block the operation
    • Require a higher level of assurance using two-factor authentication
    • End a current session
    • Receive a notification
    • Do nothing at all (useful for testing)
You can do a lot with these pieces. Here are some ideas.
  • Lock out specific geographical areas—Your org has remote offices and a global presence. To comply with international law, you want to restrict access to the Salesforce org. Set up policies to limit access from specific countries or to obtain alerts when unusual login activity occurs, like the same user logging in from two different places.
  • Securely access confidential data—You have sensitive, confidential data in your quarterly Salesforce dashboards. You want to ensure that teams accessing the dashboards use two-factor authentication (2FA) before viewing this data. Create a policy monitoring specific reports and requiring everyone to use 2FA before getting access.

These examples are just a few of the things you can do with Transaction Security. Look at the online help examples for more ideas.