Triggers Reference
Triggers are the events that wake an automation rule. This page lists all 16 triggers the engine supports, what each one gives the rule to work with, and example use cases. Rules have exactly one trigger; conditions and the action then determine whether and how the rule responds.
In the rule editor the triggers are grouped as Trust signals (Score Updated, Segment Changed, Checkout Blocked, Shipping Anomaly), Order events (Order Placed, Order Completed, Refund Processed, Dispute Recorded), Fraud signals (Chargeback Filed, Linked Accounts Detected, Card Testing Attack, Challenge Failed) and Customer status changes (Customer Blocked, Customer Unblocked, Customer Allowlisted, Customer Allowlist Removed).
Four triggers are order-bearing — they carry an order context, so they’re the only triggers that can use order-only conditions and order-only actions: order_placed, order_completed, refund_processed, and dispute_recorded.
Customer Lifecycle Triggers #
Score Updated #
Fires every time a customer’s trust score is recalculated and saved — including recalculations that leave the score unchanged.
- Event ID:
score_updated - Context: the customer record, with the new score and segment already saved
- Use case: Alert when a customer’s score drops below 30 (condition
trust_score < 30)
Segment Changed #
Fires only when a recalculation moves the customer into a different segment.
- Event ID:
segment_changed - Context: the customer record, already in the new segment
- Use case: Block customer automatically on transition to Critical (condition
segment = critical)
Customer Allowlisted #
Fires when a customer is added to the allowlist — from the admin, a bulk action, the REST API or an automation rule.
- Event ID:
customer_allowlisted - Context: the customer record, now allowlisted, unblocked, at score 100 and segment VIP
- Use case: Send a webhook to your CRM when a customer is allowlisted
Customer Allowlist Removed #
Fires when a customer is removed from the allowlist.
- Event ID:
customer_allowlist_removed - Context: the customer record; the score is recalculated from real signals shortly after
- Use case: Re-evaluate a customer’s standing once allowlist protection is lifted
Customer Blocked #
Fires whenever a block is applied — from the admin, a bulk action, the REST API, an automation rule, or Pro’s auto-block after lost disputes.
- Event ID:
customer_blocked - Context: the customer record, now blocked
- Use case: Webhook to an internal system when a customer is blocked
Customer Unblocked #
Fires when a customer is unblocked.
- Event ID:
customer_unblocked - Context: the customer record, now unblocked
- Use case: Notify support when a previously blocked customer is reinstated
Order Lifecycle Triggers #
All four order lifecycle triggers are order-bearing — they carry an order context, so they’re the only triggers that can use order-only conditions (order_total, coupon_total, payment_method, shipping_country, billing_country, country_mismatch) and order-only actions (Hold Order, Cancel Order, Require Verification).
Order Placed #
Fires once per order placed through the classic or block checkout, after the order is saved and before the customer pays. Retrying a failed payment on the same order doesn’t fire it again. Orders created in the admin, through the WooCommerce REST API or as subscription renewals don’t go through checkout, so they don’t fire it.
- Event ID:
order_placed - Context: the order and the customer record
- Use case: Hold orders from Risk/Critical customers automatically. From 1.3.23 Hold Order, Cancel Order and Require Verification wait for the payment on these orders — see Actions Reference
Order Completed #
Fires when an order reaches the completed status.
- Event ID:
order_completed - Context: the order and the customer record
- Use case: Allowlist customers after a run of clean, completed orders
Refund Processed #
Fires once for each WooCommerce refund created on an order.
- Event ID:
refund_processed - Context: the order, the customer record and the refund (amount, full or partial, classification, reason, cumulative ratio and the other refund-only fields)
- Use case: Alert when a high-value refund pushes return rate over threshold
Dispute Recorded #
Fires when a dispute is recorded against an order — ingested from Stripe or WooPayments, or entered manually on the order screen.
- Event ID:
dispute_recorded - Context: the order (when it can still be loaded) and the customer record. If the order can’t be found, the rule runs without it and order-only conditions and actions can’t apply
- Use case: Flag the customer for review the moment a dispute lands on one of their orders
Detection Module Triggers #
Checkout Blocked #
Fires when TrustLens rejects a checkout because the customer is blocked (with Enable Blocking on), and when Card-Testing Defense first locks out a device whose checkout carried a billing email.
- Event ID:
checkout_blocked - Context: the customer record for the email used at checkout
- Use case: Notify ops when a blocked customer keeps trying to check out
Chargeback Filed #
Fires together with Dispute Recorded every time a dispute is recorded (auto-ingested or manually entered). It carries no order — use Dispute Recorded when you need to act on the order.
- Event ID:
chargeback_filed - Context: the customer record, with dispute counters already updated
- Use case: Auto-block customers on first chargeback if score is low
Linked Accounts Detected #
Fires when the Linked Accounts module finds that a customer shares a shipping or billing address, phone number or payment token with at least one other account (a shared IP or device alone never links accounts). The check runs after each order is placed and when Historical Sync rebuilds a customer’s fingerprints, so it fires again on later orders while the links remain.
- Event ID:
linked_accounts_detected - Context: the customer record of the account being checked, with its linked-account count already updated
- Use case: Send a webhook (through Zapier or Make if the destination is Slack) when a customer is linked to 3 or more accounts
Card Testing Attack Detected #
Fires when velocity rules trip a fingerprint lockout. Only attempts that carried a billing email can be tied to a customer; attacks without one are handled by Card-Testing Defense but don’t reach automation rules.
- Event ID:
card_testing_attack - Context: the customer record for the billing email (it may not exist yet — Block Customer and Flag for Review create one)
- Use case: Send an email or webhook to your alerting channel; flag the associated customer email for review
Challenge Failed #
Fires when a checkout is rejected because the browser challenge (Card-Testing Defense → Browser Challenge) was missing or failed. Unlike Card Testing Attack, it fires on the first unearned attempt, so it catches attackers who rotate their identity on every try. Attempts without a billing email are ignored.
- Event ID:
challenge_failed - Context: the customer record for the billing email (it may not exist yet)
- Use case: Flag the email for review, or alert your team when challenge failures appear
Shipping Anomaly Detected #
Fires when an order completes and the Shipping Anomalies module scores the customer’s addresses as anomalous (a negative signal).
- Event ID:
shipping_anomaly - Context: the customer record
- Use case: Flag the customer for review when an anomaly coincides with a low trust score
Trigger Context Variables #
Rules don’t receive the raw event payload. Conditions are evaluated against a fixed set of fields:
| Fields | Available In |
|---|---|
Customer fields — trust_score, segment, total_orders, total_disputes, linked_accounts and the rest of the 25 |
Every trigger, once the customer has a TrustLens record. Without a record (e.g. a first card-testing attempt) customer conditions don’t match |
Order fields — order_total, coupon_total, payment_method, shipping_country, billing_country, country_mismatch |
Order Placed, Order Completed, Refund Processed, Dispute Recorded |
Refund fields — refund_amount, refund_type, refund_ratio and the rest of the 15 |
Refund Processed only |
Card details, decline codes, fingerprint hashes and dispute amounts are not available as conditions. See Conditions Reference for the full field list.
Picking the Right Trigger #
Choose the most specific trigger that fits. If you want to act on chargebacks, use chargeback_filed — not score_updated filtered by “score dropped.” The specific trigger is faster, clearer, and less brittle.
Use generic triggers (like score_updated) for cross-cutting workflows where the cause matters less than the effect. Remember it fires on every recalculation, so pair it with conditions — the one-hour cooldown keeps it from repeating customer-level actions within the hour.
Trigger Combinations #
Rules have one trigger. To respond to multiple triggers with the same action, create multiple rules pointing to the same outcome. The save-time validator checks each rule on its own; it doesn’t compare rules with each other, so nothing stops several rules firing on overlapping events.
Common pattern: a “block customer” effect achieved by three rules with triggers segment_changed (to Critical), chargeback_filed (with conditions), and linked_accounts_detected (with a linked_accounts threshold). Same action; different entry points.
Updated on October 18, 2026
