Transaction Security
Transaction Security is a framework that intercepts real-time events and applies appropriate actions to monitor and control user activity. Each transaction security policy has conditions that evaluate events and the real-time actions that are triggered after those conditions are met. The actions are Block, Multi-Factor Authentication, and Notifications. Before you build your policies, understand the available event types, policy conditions, and common use cases. Transaction Security is included in Real-Time Event Monitoring.
Required Editions
| Available in both Salesforce Classic (not available in all orgs) and Lightning Experience. |
Available in: Enterprise, Unlimited, and Developer Editions Requires Salesforce Shield or Salesforce Event Monitoring add-on subscriptions. |
Condition Builder vs. Apex
Condition Builder is a Setup feature that allows you to build policies with clicks, not code. Policies monitor events, which are categories of user activity built on objects in the SOAP, REST, and Bulk APIs. When you build your policy using Condition Builder, you choose which fields on these objects you want to monitor for customer activity. Because your policy’s actions are conditional to the fields that users interact with, these fields are called conditions. When you create a policy, you choose the conditions you want your policy to monitor and the action the policy takes when the conditions are met. The conditions available in Condition Builder are a subset of all the event objects fields and vary based on the objects.
If you create an Apex-based policy, you can use any of the event object’s fields.
For example, Records isn’t available as a Condition Builder condition for the ReportEvent event
object. But you can use the ReportEvent.Records field in an
Apex class that implements the TxnSecurity.EventCondition
interface. Visit the API Object Reference to view event object fields.
Conditions at a Glance
| Event Object | Conditions Available in Condition Builder | Actions |
|---|---|---|
| ApiEvent | API Type, API Version, Application, Client, Elapsed Time, Operation, Platform, Queried Entities, Query, Rows Processed, Session Level, Source IP, User Agent, User ID, Username | Block, Notifications |
| ApiAnomalyEventStore | User, Username, SourceIp, Score, QueriedEntities, Operation, RowsProcessed, UserAgent | Notifications |
| BulkApiResultEventStore | Query, SessionLevel, SourceIp, UserId, Username | Block, Notifications |
| CredentialStuffingEventStore | AcceptLanguage, LoginUrl, Score, SourceIp, UserAgent, UserId, Username | Notifications |
| FileEventStore | Can Download PDF, Content Size, Content Download ID, Content Version ID, Evaluation Time, File Action, File Name, File Source, File Type, Is Latest Version, Policy Outcome, Process Duration, Session Level, Source IP, Transaction Security Policy ID, User ID, Username, Version Number | Block, Notifications |
| ListViewEvent | Application Name, Developer Name, Event Source, List View ID, Name, Name of Columns, Number of Columns, Order By, Owner ID, Queried Entities, Rows Processed, Scope, Session Level, Source IP, User ID, Username | Block, Notifications, Multi-Factor Authentication (for UI logins) Multi-factor authentication isn’t supported for list views in Lightning pages, so the action is upgraded to Block. |
| LoginEvent | API Type, API Version, Application, Authentication Method Reference, Browser, Country, Login Subtype, Login Type, Login URL, Platform, Session Level, Source IP, TLS Protocol, User ID, User Type, Username | Block, Notifications, Multi-Factor Authentication (for UI logins) |
| PermissionSetEventStore | Event Source, Operation, Permission Type, User Count, User ID, Username | Block, Notifications |
| ReportAnomalyEventStore | Report, Score, SourceIp, UserId, Username | Notifications |
| ReportEvent | Dashboard ID, Dashboard Name, Description, Event Source, Format, Is Scheduled, Name, Name of Columns, Number of Columns, Operation, Owner ID, Queried Entities, Report ID, Rows Processed, Scope, Session Level, Source IP, User ID, Username | Block, Notifications, Multi-Factor Authentication (for UI logins) |
| SessionHijackingEventStore | CurrentUserAgent, CurrentIp, CurrentPlatform, CurrentScreen, CurrentWindow, PreviousUserAgent, PreviousIp, PreviousPlatform, PreviousScreen, PreviousWindow, Score, SourceIp, UserId, Username | Notifications |
- Types of Transaction Security Policies
You can create transaction security policies on these Real-Time Event Monitoring events. - Essential Transaction Security Policies to Enhance Your Security Posture
Transaction Security Policies (TSPs) provide a dynamic and automated way to monitor and control user interactions with your Salesforce data, adding a crucial layer of security by responding to suspicious activities in real-time. These TSPs are some of the best for enhancing your security posture. TSPs are organized by Security Lenses, a group of topics that shows how security teams usually look at risk and enforce policy. - Transaction Security Actions and Notifications
When a real-time event triggers a transaction security policy, you can block a user or enforce multi-factor authentication (MFA). You can also optionally receive in-app or email notifications of the event. - Build a Transaction Security Policy with Condition Builder
Create a transaction security policy without writing a line of code. Condition Builder, available in Real-Time Event Monitoring, gives you a declarative way to create customized security policies to protect your data. - Create a Transaction Security Policy That Uses Apex
Use Setup to create an transaction security policy that uses Apex. You can specify an existing Apex class or create an empty class that you then code. The Apex class must implement theTxnSecurity.EventConditioninterface. - Best Practices for Writing and Maintaining Transaction Security Policies
Transaction security policy management isn’t always easy, especially when you have many policies. To make sure that your policies remain functional, write and maintain them using these best practices. Well-structured and tested policies keep your employees and customers connected, productive, and secure. - Transaction Security Metering
Transaction Security uses resource metering to help prevent malicious or unintentional monopolization of shared, multi-tenant platform resources. Metering prevents transaction security policy evaluations from using too many resources and adversely affecting your Salesforce org. - Exempt Users from Transaction Security Policies
If you have transaction security policies that work well for most users, but not all, you can assign specific users the Exempt from Transaction Security user permission. Assign this permission only when transaction security policy metering regularly blocks business-critical actions. For example, assign it to users who make bulk or automated bulk API calls. You can assign this user permission to integration users or admins responsible for transaction security policies who you don't want to get blocked. - Test and Troubleshoot Your New Policy
If your transaction security policy isn't behaving as you expect, check out these testing and troubleshooting tips to diagnose the problem.
