Not verified hands-on. This article was written from primary documentation rather than reproduced in an org, so it carries no tested-release badge. If you run it and something differs, say so in the comments and it gets tested and corrected.

The quick version: a transaction security policy watches a real-time event, evaluates a condition, and takes an action when the condition matches. Two ways to write the condition: Condition Builder for declarative filters on event fields, or an Apex class for anything more involved. The action is where the value is, because this is the one part of Event Monitoring that can stop something rather than record it.

The shape of a policy

Every policy names an event type, a condition, and an action. The event types are the real-time events: login, API, report, list view, logout, and the threat detection events such as credential stuffing, session hijacking and report anomaly.

Whether a policy can block depends on the event. Some events are evaluated synchronously, so a block actually prevents the operation. Others are evaluated after the fact, so the only sensible actions are notification and freezing the user. Check which category your event falls into before promising anyone that a policy will prevent an export.

Condition Builder

Condition Builder is a filter over the event’s fields, assembled in Setup without code. Report event fields include things like the number of rows and the export format. API event fields include the operation and the row count. Login events expose the login type and source.

Typical declarative policies:

  • Notify when a report with more than a set number of rows is exported to CSV.
  • Block API queries returning very large row counts from a named profile.
  • Require a stronger authentication factor when a login event matches a risky pattern.
  • Freeze a user on a credential stuffing event.

Condition Builder handles most real requirements. Reach for it first, because a declarative policy is readable by the security team and an Apex one is not.

The Apex option

When the condition needs data the event does not carry, you write a class implementing the event condition interface. The method receives the event and returns a boolean.

global class LargeExportCondition
        implements TxnSecurity.EventCondition {
    public boolean evaluate(SObject event) {
        ReportEvent e = (ReportEvent) event;
        // combine event data with org data, then decide
        return e.RowsProcessed > 5000;
    }
}

There is a synchronous interface and an asynchronous one, matching the two evaluation modes. The older policy condition interface from the original release of this feature is superseded. New work should use the event condition interfaces.

Keep the class trivial. It runs in the path of a user action, it is subject to governor limits, and an exception in your condition is a support incident with no obvious cause. Querying other objects inside a condition is possible and usually a mistake.

Actions, and the one that will get you

Block, notify, freeze the user, end the session, and step up authentication, depending on the event. Notification can go by email or in-app to a named set of recipients.

Policies apply to administrators unless the condition excludes them. A block policy on API events written without a carve-out will eventually stop a deployment, a data load or an integration at the worst moment. Build the exclusion into the condition deliberately rather than discovering it.

How to roll one out without an incident

The sequence that works:

  • Enable the event and collect a few weeks of data first. You cannot pick a sensible threshold without knowing what normal looks like.
  • Create the policy with notification only. Leave it there long enough to see the false positives.
  • Tune the condition until the notifications are all genuinely interesting.
  • Only then switch to block or freeze, and only if there is somebody to unfreeze people.
  • Write down who responds and how, because a freeze action with no runbook is a self-inflicted outage.

Policies are metadata and deploy between orgs, so build and tune in a sandbox that has representative volume. A sandbox with fifty records will never produce a useful threshold.

What it does not do

Transaction security covers the events Salesforce publishes, not everything a user can do. There is no policy for “prevent editing this field” or “stop this Apex class running”. Those are permissions and validation rules. Policies are for patterns of access that look wrong in aggregate, which is a genuinely different problem from record-level authorisation.

Frequently asked

Do I need Shield for this? Transaction security policies depend on Real-Time Event Monitoring, so check what your entitlement covers for the specific event you want.

Can a policy block a report export? For report events evaluated synchronously, yes. Test the exact scenario, including the export format, before relying on it.

Will a policy affect my integrations? If it watches API or login events, assume yes. Exclude your integration users explicitly.

How many policies should an org have? Few. Three well-tuned policies with owners beat twenty that fire into an unread mailbox.