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.