Get Started with Transaction Security
- Describe the benefits of transaction security.
- Explain what policies, actions, and notifications are.
- State at least three use cases for 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.
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.
Available—Any policy you create, plus the example
policies that Salesforce
supplies. These policies are listed on the Salesforce
Transaction Security Policies page.
- 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.
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.
- 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:
- 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)
- 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.