Create Transaction Security Policies
- Enable Transaction Security.
- List the uses of different notification types.
- Use real-time actions appropriately.
- Define your own policies.
- Enable and disable policies.
- Test a new policy.
The first thing to do before you can create your own policies and use the supplied policies is to enable Transaction Security. You have to “turn it on” before you can start working.
Go to the Transaction Security page. From Setup, enter Transaction in the Quick Find box, press Return, and click Transaction Security. If you’ve never visited this page before, select Enable custom transaction security policies and click Save to activate Transaction Security and install the supplied policies.
Now you see the available policies. Because you haven’t created any policies of your own yet, only the two supplied policies are shown.
Congratulations! Transaction Security is now ready to use in your org.
Now that you know what Transaction Security is, it’s time to learn how to use it. To start, let’s create a simple policy to block anyone using the Android operating system. There’s nothing wrong with Android! This is just an example. Later we’ll explain why you might want to block an operating system.
On the main Transaction Security page, click New.
You get a screen with a bunch of things to fill in, but don’t worry. You can’t go too far wrong because most of the values you have to supply come from picklists or are created for you.
- Don’t select Enable just yet. We’ll do that later.
- Let’s call the policy Block Android. What you enter in the Name field automatically sets the API name, in this case, BlockAndroid. The API name is what the policy is called within your org and by Apex code.
- The Event Type is Login, and that’s the default, so we’re good there.
- Select Email Notification. If you’re an admin, choose
yourself as the recipient. The recipient has to be an admin.
When an email notification is sent, there can be some delay before you receive the message. An in-app notification goes directly to your mobile device and is often received sooner than email. Use an in-app notification when you want to know as soon as possible when a policy is triggered, and remember to keep your mobile device with you!
- Our real-time action is Block, because we want to block Android users. Not all events support all actions. For this Login event, we could instead require all Android users to use two-factor authentication for additional assurance. Another action option is to require the user to end an existing session to not exceed the session limit. We could also select no action and just receive a notification.
- Don’t change the Generate Apex choice for Apex Policy. Having Transaction Security create the Apex code for your policy is the easiest way to go.
- For Execute Policy As, choose the same person that you selected for Recipient.
- Policy conditions let you fine-tune the policy. You don’t want to block all login attempts, so we narrow it down to logins using a specific browser or application. Because we want to block only Android users, we create a condition for Platform, where If the Platform matches is Android 9. Right now, we need a specific Android release, so we’ll just choose 9.
- That’s all. Your page should look like this.
- To add your new policy to the list of available policies, click Save.
After creating a policy, review it to make sure that you’ve got everything right.
On the Transaction Security Policies page, click Edit next to the Block Android policy. That displays all the policy’s settings that you can edit. By the way, this isn’t your last chance to modify the policy. You can edit it at any time.
When you’re sure it’s the way you want, select Enable and then click Save. Click Back to List: Custom Policies to return to the main Transaction Security page.
Now the policy is enabled. To test it out, try logging in to your org from an Android device. You see a message saying that you can’t log in, and the notification recipient (also possibly you) gets an email from Transaction Security.