Use Apex in Transaction Security Policies
- Describe how Apex is used to implement your transaction security policies.
- Describe transaction security events and policies.
- Explain the programming side of transaction security policies.
Working with Apex can be intimidating. Well, don’t worry—while we don’t go into great detail here, we do cover everything you need to know to edit the Apex part of your Transaction Security policies. You don’t have to edit any of the code that’s part of your policy. However, when you need to fine-tune a policy, such as having it trigger for a very specific event, editing the Apex is the way to go. Transaction Security provides a way for you to edit your code in Setup, so you don’t need a software development environment. You also don’t need any programming experience, because we show you how to make changes.
- An Apex class is a self-contained unit of code. The name of the class is a handy way to refer to what it does. Transaction Security uses the Event class to contain event information for all policies. There’s also one class for each policy implementation, and we’ll call it the policy’s class. A policy class is named by concatenating the policy’s API name with PolicyCondition, so each class has a unique name.
- An interface connects two things, for example, the event we’re watching for and the action we want to take when the event occurs. Transaction Security uses the PolicyCondition interface to evaluate events against a policy. Each policy has a unique interface implementation because each policy is different.
- The interface class is DataLoaderLeadExportCondition. This is the Apex class that you associated with our Lead Data Export Policy when you created the policy.
- The implementation is the code for the DataLoaderLeadExportCondition class. This is the part you modify to fine-tune your policy.
- The interface is always PolicyCondition for Transaction Security. If you take a look at the DataLoaderLeadExportCondition class, it implements the TxnSecurity.PolicyCondition interface in the first line of code.
The other class we use is the event, or action, that triggers the policy. When someone logs in, accesses a resource, updates an account, or just about anything else, an event is created in the database. The events we care about are represented in Apex by the Transaction Security Event class. The Event class contains all sorts of interesting information, like when the event happened, who created it, where it happened, and what it was. We cover events more in a bit.
Whenever you create a policy, you must associate an Apex PolicyCondition implementation with the policy.
Transaction Security checks every event to see if it matches any of your policies. If a match is found, the condition is run to see if the event meets the criteria to trigger the policy. If so, Transaction Security takes the action and issues any notifications for that policy. Continuing with our example, DataLoaderLeadExportCondition runs only when Transaction Security gets a data export event. Transaction Security triggers the policy only if DataLoaderLeadExportCondition says that the event meets the policy criteria.
If you’re new to Apex, don’t worry. We explain everything in plain language.
Let’s take a look at the Apex code that implements the Transaction Security policy. This is a plain-language explanation of the code—no programmer jargon required.
In the list of policies, click the Apex condition that’s associated with your policy: DataLoaderLeadExportCondition. Let’s take a short stroll through the code.
The first few lines describe the Apex components we’re creating. Line 1 says that the Apex class name is DataLoaderLeadExportCondition and that this class implements the transaction security policy condition interface. This information tells Transaction Security that when the event we defined for this policy occurs, run this code. Line 2 says that the class gets one parameter, which is the event that just happened. Lines 3 and 4 are just comments that describe some of what’s going on in the following lines of code.
The only thing a PolicyCondition implementation does is evaluate the event to check whether to trigger its action. For now, we want to find out how many records a user tried to export from Salesforce. That information isn’t included in the event, but there’s a way to find it. We start by creating a map object that contains some information we need, including the number of records a user tried to export, the amount of time it took the export operation to run, and the type of records the user tried to export.
Beginning in Line 11, the code evaluates whether it needs to block the user. If the user indeed tried to export any number of leads, the code determines whether the user tried to export more than 2,000 leads. If the user did try to export more than 2,000 leads, or if that export operation took more than one full second, the code triggers the alarm. It blocks the user and sends an email alert.
This entire checking process takes a fraction of a second.