Transaction Security
Transaction Security is the Salesforce policy framework that monitors real-time user activity, detects suspicious patterns, and takes automated action: block the action, require multi-factor authentication, end the session, or notify an admin.
Definition
Transaction Security is the Salesforce policy framework that monitors real-time user activity, detects suspicious patterns, and takes automated action: block the action, require multi-factor authentication, end the session, or notify an admin. Policies are configured in Setup, Security, Transaction Security Policies, and they evaluate against streaming Event Monitoring data, including login events, report exports, API queries, list view exports, and credential changes. The policy framework is the action layer that sits on top of the observability layer.
Transaction Security is part of the Shield product family but the Enhanced Transaction Security version (rebuilt in 2020) is included with Salesforce Shield. The older Transaction Security 1.0 used Apex implementing the TxnSecurity.PolicyCondition interface. The new Enhanced Transaction Security uses Condition Builder, a declarative editor that lets admins build policies without code. Both versions coexist for backward compatibility but the new policies replace the old ones for all new use cases. Policies fire in milliseconds against the streaming event stream and can block actions before the data leaves the platform.
How Transaction Security policies enforce real-time security
The event types Transaction Security monitors
Enhanced Transaction Security policies attach to specific event types: ApiAnomalyEvent, ApiEvent, CredentialStuffingEvent, ListViewEvent, LoginAsEvent, LoginEvent, ReportAnomalyEvent, ReportEvent, BulkApiResultEvent, ConcurrentSessionEvent, FilesEvent, ReadEvent, and others. Each event type carries a payload with the user, timestamp, IP, and event-specific fields. The policy evaluates the payload against the configured conditions. A policy on LoginEvent might check the source country, the login type, and the user agent. A policy on ReportEvent might check the row count, the report type, and the time of day.
Built-in policy templates
Salesforce ships several built-in policy templates. Credential Stuffing detects rapid sequences of login attempts using leaked credentials. Concurrent User Sessions prevents the same user from holding more than N active sessions. Impossible Travel detects logins from geographically distant locations within a short time window. Report Anomalies flags reports that return more rows than the user typically requests. List View Export flags large exports from list views. Each template is a starting point; admins can clone and customize. Most orgs start with the built-in templates and extend them as patterns emerge.
Policy actions: block, MFA, end session, notify
Each policy has one or more actions. Block immediately denies the action and returns an error to the user. End Session terminates the session. Require Two-Factor Authentication injects an MFA challenge before the action proceeds. Send Email notifies an admin distribution list. Send In-App Notification triggers an admin alert in the Setup UI. Actions can be combined: block the action and send an email is a common pattern. The platform applies the action in real time, before the event finishes processing.
Condition Builder and policy logic
Enhanced Transaction Security uses a declarative Condition Builder. Each policy has one or more conditions: Field, Operator, Value. Field is an event payload attribute (UserId, LoginType, RowsProcessed). Operator is comparison logic (equals, not equals, in, not in, greater than, less than). Value is the threshold. Multiple conditions combine with AND or OR logic. The framework supports nested conditions for complex patterns, like ((country = "USA" AND login_type = "Application") OR (country = "China" AND login_type = "API")). The result is policy logic that approximates a small DSL without requiring Apex.
Apex-based policies for custom logic
When Condition Builder is not enough, admins can write Apex classes that implement the TxnSecurity.EventCondition interface. The class receives the event payload, runs custom logic, and returns a boolean. This pattern is used for cross-event correlation (a login followed by a large report export within 60 seconds), integration with external risk scoring systems, or any logic that requires a SOQL query or a callout. Apex-based policies are more flexible but more brittle: a bug in the class can stall the event stream or generate false positives at scale.
Real-time vs near-real-time evaluation
Policies evaluate in real time against streaming events. The latency between the user action and the policy decision is sub-second. This matters for blocking actions: a Block action on a ReportEvent must fire before the report renders, not after the data has been viewed. The platform achieves this by intercepting the event in the event stream and applying the policy synchronously. Apex-based policies that perform SOQL queries can add latency. Most orgs design policies to be lightweight and offload heavy correlation to external SIEM systems that consume Event Monitoring data downstream.
Coverage and licensing
Enhanced Transaction Security is included with Salesforce Shield, which bundles Event Monitoring, Field Audit Trail, and Platform Encryption. Without Shield, the org has Transaction Security 1.0 (legacy Apex-only policies on a limited event set) but not Enhanced Transaction Security. The licensing matters: an org that wants no-code policies on streaming events must buy Shield. For organizations comparing Shield to standalone Event Monitoring, the Transaction Security action layer is one of the biggest reasons to take the full Shield bundle.
Building a Transaction Security policy
Building a Transaction Security policy is a five-step Setup workflow: pick the event type, define the conditions, select the actions, set the notification recipients, and activate. The platform applies the policy to every matching event from that point forward.
- Confirm Shield licensing and event types
Setup, Quick Find Transaction Security, click the link. Enhanced Transaction Security requires Salesforce Shield. Confirm the org has the license. Without it, only Transaction Security 1.0 policies are available.
- Click New from the policy list
The Transaction Security Policies page shows existing policies. Click New, pick Custom Policy (or pick one of the built-in templates: Concurrent User Sessions, Login from Multiple IPs, Suspicious Report Anomaly).
- Pick the event type and define conditions
The wizard asks for an event type (LoginEvent, ReportEvent, ApiEvent, others). Build conditions in the Condition Builder: Field, Operator, Value. Combine with AND or OR. Test the conditions against historical event data using the preview feature.
- Select policy actions
Pick the action: Block, End Session, Require Two-Factor Authentication, Send Email, Send In-App Notification. Combine if needed. Block must be considered carefully: blocking real activity creates user impact.
- Add notification recipients
For email and in-app actions, specify the admin email list. For high-volume policies, use a security distribution list rather than individual addresses. Avoid notification fatigue.
- Activate and monitor
Save the policy in Inactive state first. Test against the event stream by inspecting the policy log for matches. Once confident, activate. Monitor the TransactionSecurityPolicy hit count for the first week to catch unexpected false positives.
The streaming event the policy attaches to: LoginEvent, ReportEvent, ApiEvent, ListViewEvent, CredentialStuffingEvent, others. Each carries its own payload schema.
Field-Operator-Value rule applied to the event payload. Multiple conditions combine with AND or OR. Nested groups supported.
Block, End Session, Require Two-Factor Authentication, Send Email, Send In-App Notification. Multiple actions per policy.
Email addresses or in-app admin alert targets. Use distribution lists to avoid losing alerts when individuals change roles.
Custom logic via TxnSecurity.EventCondition. Used when Condition Builder is insufficient (cross-event correlation, callouts, SOQL queries).
- Block actions create real user impact. Test extensively against the event stream in preview mode before enabling Block. False positives translate directly to angry users and support tickets.
- Enhanced Transaction Security requires Salesforce Shield. Without it, only the older Apex-only Transaction Security 1.0 is available, with a much smaller event surface.
- Apex-based policies that perform SOQL or callouts can add latency. The platform evaluates policies synchronously, so slow Apex blocks the user action while the policy runs.
- Policies on ReportEvent fire before the report renders. The platform intercepts the event in the streaming pipeline. A poorly designed policy can block legitimate report use.
- Notification fatigue is real. A noisy policy sending hundreds of emails per day gets ignored. Tune thresholds to minimize false positives and route alerts to security operations centers, not individual admins.
Trust & references
Straight from the source - Salesforce's reference material on Transaction Security.
- Transaction Security PoliciesSalesforce Help
- Enhanced Transaction SecuritySalesforce Help
- TxnSecurity.EventCondition InterfaceSalesforce Developers
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is the primary benefit of Transaction Security for Salesforce administrators?
Q2. In which area of Salesforce would you typically find Transaction Security?
Q3. Why is understanding Transaction Security important for Salesforce admins?
Discussion
Loading discussion…