Establish an Enhanced Transaction Security Policy Utilizing Apex

Utilize the Setup interface to craft an enhanced transaction security policy that leverages Apex. You have the option to designate either an existing Apex class or generate a blank class which you can subsequently customize. It’s imperative that the chosen Apex class adheres to the TxnSecurity.EventCondition interface.

It’s possible to establish multiple policies for a single event type, but we advise avoiding any overlap in policies and their associated actions. If several policies with the same action are triggered by a specific event, the order in which they execute is unpredictable.

1. From Setup, in the Quick Find box, enter Transaction Security, and then select Transaction Security Policies.
2. Click New, and then select Apex.
3. Click Next.
4. Select an event that your policy is built on.For example, if you want to track API calls in your org, select API Event. If you want to monitor when users view or export reports, select Report Event. See Enhanced Transaction Security for the full list of available events.
5. Select the Apex class that implements your policy. If you haven’t already created the class, select New Empty Apex Class.
6. Click Next.
7. Select the action that the policy performs when triggered.The available actions vary depending on the event type. For more information, see Enhanced Transaction Security Actions and Notifications.

Important Information

The two-factor authentication action is not accessible in the Salesforce mobile app, Lightning Experience, or via API for events. In such cases, the block action is employed instead. For instance, if a two-factor authentication policy is activated during a list view operation carried out via the API, Salesforce will block the API user.

1. If applicable, choose a block message or notification type and recipient.
2. Enter a name and description for your policy.Your policy name must begin with a letter, not end with an underscore, and not contain two consecutive underscores.
3. Optionally, enable the policy.If you chose to create an Apex class, don’t enable the policy yet because you must first add code to the class.
4. Click Finish.Your new policy appears in the Policies table. If you chose to create an Apex class, its name is the 25 characters of your policy name without spaces appended with the EventCondition string. If your policy is named “My Apex Class,” your Apex class is auto-generated as MyApexClassEventCondition. The class is listed in the Apex Condition column.
5. Click the name of your Apex class if you want to edit it.If you chose to create an Apex class, you must add the implementation code. Salesforce adds this basic code to get you started.

global class MyApexClassEventCondition implements TxnSecurity.EventCondition {

  public boolean evaluate(SObject event) {
    return false;
  }

}

When you delete a transaction security policy that uses Apex, the implementation class isn’t deleted. You can either delete this Apex class separately or reuse it in another policy.

Don’t include DML statements in your Apex-based policies because they can cause errors. When you send a custom email via Apex during transaction policy evaluation, you get an error, even if the record isn’t explicitly related to another record. For more information, see Apex DML Operations in the Apex Reference Guide.

• Enhanced Apex Transaction Security Implementation Examples
  Here are examples of implementing enhanced Apex transaction security.
• Asynchronous Apex Example
  When executing a transaction security policy, use an asynchronous Apex process to offload time-consuming operations, such as sending a notification email to an external recipient.
• Enhanced Transaction Security Apex Testing
  Writing robust tests is an engineering best practice to ensure that your code does what you expect and to find errors before your users and customers do. It’s even more important to write tests for your transaction security policy’s Apex code because it executes during critical user actions in your Salesforce org. For example, a bug in your LoginEvent policy that’s not caught during testing can result in locking your users out of your org, a situation best avoided.