Security, Event Monitoring & Operations

Transaction Security is a circuit breaker—not a permission model

JSBC Labs26 October 20268 min read

A safety net is not the floor

A company gives broad report-export access to hundreds of users, then creates a Transaction Security policy that blocks suspiciously large exports. The policy appears to solve data loss prevention. In reality, the organisation has placed a runtime rule between an over-privileged identity and sensitive data, then made that rule carry the whole security model.

Salesforce describes Transaction Security policies as controls that evaluate events and take action when defined combinations occur. Salesforce Well-Architected positions them as real-time intervention alongside Event Monitoring. The JSBC Labs view is that they are circuit breakers: valuable controls for high-risk behaviour and anomalies, but a second line of defence after permissions, sharing, field security, session controls and sound data classification.

Start with a threat, not a checkbox

Each policy should name the scenario it interrupts: bulk extraction of restricted data, API use from an unexpected context, suspicious permission assignment, credential stuffing or session hijacking. Define the protected asset, actor, event, threshold, expected response and business owner. ‘Improve security’ is not a testable policy objective.

Choose evidence that differentiates risk from normal work. A 10,000-row export may be suspicious for a recruiter but routine for an approved analytics service. Add identity type, permission, object, operation, location, channel and time where supported. Prefer a narrow condition with an explainable purpose over one global threshold that generates exceptions faster than the team can review them.

Match the action to the consequence

Transaction Security can take preventive or detective actions, including blocking an operation, requiring additional authentication in supported contexts, or taking no action while notifying. These options have different business costs. Blocking protects immediately but can interrupt legitimate work; notification preserves service but permits the action to complete.

Use block where the risk is unacceptable and the event is sufficiently specific. Use step-up authentication when stronger identity evidence materially changes the decision and the channel supports it. Use observe-and-notify while establishing a baseline or when an automated block could create greater harm. Salesforce notes that MFA actions are not available in every channel and can become a block instead, so test the actual UI and API paths—not only the policy label.

Understand policy precedence

Multiple policies on the same event do not behave like an unordered list of independent alerts. Salesforce documents a priority sequence in which block actions precede MFA and no-action policies; when an earlier policy triggers, later policies may not execute. A security team can therefore lose an expected notification or challenge because another rule ended the transaction first.

Create a policy map per event type. Show conditions, actions, notifications, exemptions and precedence, then consolidate overlapping rules where possible. Salesforce recommends maintaining only as many policies as the organisation can manage. Complexity is itself a control risk: reviewers must be able to predict which rule wins before a production incident proves it.

Treat Apex conditions as security code

Condition Builder suits many transparent thresholds. Apex conditions support logic that needs richer evaluation and implement the TxnSecurity.EventCondition interface. That flexibility introduces software risk at the enforcement point. Queries, null assumptions, expensive logic and unhandled exceptions can change whether a user is allowed to continue.

Keep conditions deterministic, small and bulk-conscious. External callouts and slow dependencies do not belong in a synchronous security decision. Put reference data in governed configuration, document every privileged lookup and return a decision that can be explained from captured evidence. Apply code review, static analysis, unit tests and controlled deployment with the same seriousness as authentication or authorization code.

Design the failure mode before activation

Salesforce warns that a faulty Apex-based login policy can fail closed and lock users out. Recovery can require Salesforce Support to disable Transaction Security before administrators can correct the code. That is not an edge case to discover after enabling a policy for every identity in production.

Test exceptions, limits and malformed event data in a sandbox. Maintain a documented break-glass identity and verify whether it is genuinely outside the affected condition without weakening normal access. Define who can disable a policy, who approves that change and which evidence must be retained. For login controls, rehearse lockout recovery and keep support escalation details available outside the org.

Govern exemptions as temporary risk

Business teams will need legitimate bulk exports, integration jobs or administrative operations that resemble threats. An exemption should identify a named identity or bounded group, business purpose, data scope, owner, approval, start date and expiry. Permanent exemption groups become shadow permission sets that bypass the control without the scrutiny applied to formal access.

Prefer service-specific policies and least-privilege machine identities over excluding broad administrator populations. Review exemptions alongside access recertification, and alert when an exempt identity performs outside its declared purpose. If legitimate work repeatedly collides with a rule, improve the policy or the process; do not normalise manual disablement before month-end.

Send evidence beyond the inbox

An email notification is not an incident-response process. Capture policy name, event type, actor, time, action, relevant condition inputs, outcome and correlation identifiers in the security monitoring platform. Salesforce Well-Architected recommends combining Transaction Security with Event Monitoring, Setup Audit Trail, custom logging and SIEM correlation because no single signal provides complete detection or forensic evidence.

Route high-severity triggers to an owned queue with response targets. Preserve logs outside Salesforce according to retention and tamper-resistance requirements. Measure false positives, repeat actors, blocked operations, exemption use and time to triage. A policy that fires daily but is never investigated provides theatre, not protection.

Release policies like production controls

TransactionSecurityPolicy is deployable metadata. Keep policies, Apex conditions and supporting configuration in source control; review changes with security and process owners; validate them against representative personas; and activate progressively. Start in no-action mode where the risk permits, compare expected and actual triggers, then move to challenge or block with a monitored rollout.

Revisit policies after permission changes, new integrations, seasonal releases and shifts in user behaviour. Retire rules whose threat no longer exists and update baselines rather than letting alerts decay. The durable architecture is layered: prevent ordinary misuse with least privilege, detect abnormal behaviour with reliable telemetry, and use Transaction Security to interrupt specific high-risk actions. A circuit breaker is powerful precisely because it is not asked to wire the whole building.