Actions Reference
Actions are what a rule does when its trigger fires and its conditions pass. Each rule has exactly one action, plus one optional text value in the editor (the “action value”) whose meaning depends on the action. Actions run immediately, in the request that fired the trigger — except Send Webhook, which is queued and retried. This page documents every available action, what it does, and how to configure it.
The Eleven Actions #
| Action | Effect |
|---|---|
| Send Email Notification | Emails a fixed alert about the customer to your notification address, or to the address in the action value |
| Add Admin Note | Appends the action value as a timestamped note on the customer’s record |
| Add Tag | Adds the tag named in the action value to the customer’s record |
| Remove Tag | Removes the tag named in the action value from the customer’s record |
| Block Customer | Sets is_blocked = true on the customer |
| Allowlist Customer | Adds the customer to the allowlist; pins score at 100 and segment at VIP |
| Flag for Review | Flags the customer for manual review — or, on an order trigger, flags the order |
| Send Webhook | POSTs a signed JSON payload to the URL in the action value |
| Hold Order (order-bearing trigger only) | Sets the order status to on-hold |
| Cancel Order (order-bearing trigger only) | Sets the order status to cancelled |
| Require Verification (order-bearing trigger only) | Marks the order as needing verification and puts it on hold |
The three order-bearing actions — Hold Order, Cancel Order, and Require Verification — act on an order, so they’re only available with an order-bearing trigger (order_placed, order_completed, refund_processed, or dispute_recorded). Saving one with any other trigger is rejected with “This action is only valid for order triggers (Order Placed, Order Completed, Refund Processed, Dispute Recorded).”
The eight customer-level actions are limited by a one-hour cooldown per rule per customer; the order actions are not. See Automation Overview.
There is no dedicated Slack action, and pointing Send Webhook straight at a Slack incoming-webhook URL doesn’t work — Slack requires a text field the TrustLens payload doesn’t include. Route the webhook through Zapier, Make or a small endpoint that reformats it for Slack.
Block Customer #
Sets the customer’s is_blocked flag to true. If Enable Blocking (Settings → General) is on, the customer can’t complete checkout. The block is logged in the customer’s event timeline, and the rule run appears there as an automation event.
Action value: the block reason, appended to the customer’s admin notes as “Blocked: …” (default: “Automated: Rule triggered”).
If the customer has no TrustLens record yet (e.g. a Card Testing Attack from a never-seen email), a minimal record is created so the block sticks.
Idempotent: The end state is the same, but re-blocking an already-blocked customer appends another note and fires the Customer Blocked trigger again.
Caution: Enable Blocking is off by default. With it off, this action sets state but doesn’t enforce — the customer can still check out. Allowlisted customers are never stopped at checkout, even when blocked.
Allowlist Customer #
Sets the customer’s is_allowlisted flag to true. It also clears any block and review flag, sets the score to 100 and the segment to VIP. Scoring short-circuits for allowlisted customers, so the score stays at 100 until they’re removed from the allowlist.
Action value: not used.
Use case: Auto-allowlist customers who hit a positive milestone — e.g. “20 completed orders, no signals” — to lock in their VIP status.
Hold Order #
Sets the order status to on-hold with the order note “TrustLens: Automation rule triggered – order held for review.” The order isn’t cancelled, but it doesn’t proceed to fulfillment until an admin reviews it and changes the status.
Action value: not used.
Use case: “Hold orders from Risk-segment customers for manual review.”
Constraint: Only valid in order-trigger contexts (the rule must have access to an order). On Order Placed, the hold waits for the payment — see Orders Awaiting Payment below.
Cancel Order #
Sets the order status to cancelled with an order note naming the rule. WooCommerce’s standard cancellation handling applies (stock restoration, cancellation emails if you have them enabled). TrustLens does not refund the payment.
Action value: not used.
Use case: “Cancel orders from Critical-segment customers automatically.”
Caution: Cancellation is harder to reverse than a hold. Prefer holds unless you’re confident. On Order Completed, Refund Processed or Dispute Recorded the order is usually already paid, and Cancel Order cancels it immediately without refunding — refund it yourself if needed. On Order Placed, a paid order is never cancelled: it’s held instead (see below).
Orders Awaiting Payment (1.3.23) #
Order Placed fires after the order is saved but before the customer pays. From 1.3.23, when Hold Order, Cancel Order or Require Verification runs on an order that is still awaiting payment (status pending, failed or checkout-draft), TrustLens doesn’t change the status straight away:
- The action is stored on the order (order meta
_trustlens_deferred_hold) and the order gets the note “TrustLens: automation rule “…” will hold this order once the payment is confirmed.” Require Verification sets its “Needs verification” mark at this point. - The rule’s run is logged as QUEUED (“Waiting for payment; applied when the payment is confirmed”).
- When the gateway confirms the payment, the order goes from pending straight to
on-holdinstead of processing (through WooCommerce’swoocommerce_payment_complete_order_statusfilter), so the shopper doesn’t get a “processing” email for an order you’re holding. - If the order reaches processing or completed another way (cash on delivery, other offline methods, an admin edit), TrustLens moves it to on-hold. If it arrives on-hold already, TrustLens just adds the note.
- The run is then logged as OK.
A deferred Cancel Order never cancels a paid order — cancelling would leave the shopper charged with no refund. The order is put on hold with the note “…asked to cancel this order, but the payment was already taken, so the order is on hold instead. If you cancel it, refund the payment too.” An order that was never paid — for example a bank transfer, which WooCommerce puts on-hold while it waits for the money — is cancelled.
A deferred action is still applied if the automation engine is paused or the Pro license lapses after the order was placed. If the customer never pays, the order stays pending and nothing is held.
Before 1.3.23 these actions changed the status during checkout, before payment. On the block checkout this could let an order through as processing without the payment being taken, and on the classic checkout the gateway moved the held order back to processing. If you used Hold Order, Cancel Order or Require Verification on Order Placed with an earlier version, check those orders’ payments.
Send Email Notification #
Sends a plain-text alert with the subject “[TrustLens] Automation Alert: {rule name}”. The body names the rule and gives the customer’s email, trust score, segment and a link to their TrustLens profile. The subject and body are fixed — there are no template variables.
Action value: optional recipient — one email address. Left blank, the alert goes to the Notification Email set under Settings → Alerts & Reports → Notifications, or to the WordPress admin email if that’s empty.
No email is sent when the customer has no TrustLens record yet. Delivery depends on your WordPress mail setup; a mail failure isn’t reported as an error in the log.
Use case: “Email the operations lead when any Risk-segment customer places a $500+ order.”
Send Webhook #
POSTs a JSON payload to the URL in the action value. The payload carries rule metadata (name, ID, trigger) and the customer’s email hash, trust score and segment — plus the refund details on Refund Processed rules. It doesn’t include order or dispute data.
Action value: the destination URL (required; it must be a valid URL that WordPress can reach).
Security: Every webhook is signed with HMAC-SHA256 using a secret TrustLens generates for your site. The signature is sent as the X-TrustLens-Signature header, equal to sha256= followed by hmac_sha256(timestamp + "." + body, secret). A X-TrustLens-Timestamp header carries the Unix epoch so receivers can reject replays. Receivers should verify the signature before trusting the payload. See Webhooks and HMAC.
Retry: Delivery is queued with Action Scheduler; identical pending deliveries are collapsed into one. Failed deliveries retry at 60s / 120s / 240s backoff. After 3 failed retries, the delivery is logged as failed.
Use case: “Send a webhook to your CRM when a customer’s segment changes to VIP.”
Add Tag (Tag Customer) #
Adds a tag to the customer’s record. Tags are de-duplicated and shown on the customer’s profile, where you can remove them with one click. They’re useful for:
- Labelling customers for your team (“manual review needed”)
- Marking customers a rule has already handled
- Pairing with Remove Tag and the Customers list’s Add Tag / Remove Tag bulk actions
Tags can’t be used as a rule condition, and the Customers list doesn’t filter by tag.
Action value: the tag name (required). The customer must already have a TrustLens record.
Use case: “Tag customers with ‘high-value-at-risk’ when their score drops below 30 and their total order value is over $5000.”
Remove Tag #
Removes a tag from the customer’s record, if present.
Action value: the tag name (required).
Use case: “Remove the ‘watch’ tag when the customer is allowlisted.”
Add Admin Note #
Appends a timestamped line to the customer’s admin notes. Unlike a tag (a short label), a note is free-text context for human reviewers — what happened, which rule fired, and why.
Action value: the note text, saved as written (no template variables). A blank value adds nothing, and the customer must already have a TrustLens record.
Use case: “When a chargeback is filed, add a note telling reviewers to check the dispute on the order screen.”
Flag for Review #
Flags the customer for manual review without blocking checkout: the customer gets a “Flagged” badge, appears under the Customers list’s Flagged status filter, and the rule name is added to their admin notes. A record is created if the customer doesn’t have one yet. Use it when an event is suspicious enough to warrant a human look but not severe enough to act automatically.
On an order trigger (Order Placed, Order Completed, Refund Processed, Dispute Recorded) the action flags the order instead: it adds the order note “TrustLens: Flagged by automation rule …” and shows a “Flagged” mark next to the order’s badge in the WooCommerce orders list. The customer isn’t flagged in that case.
Action value: not used — the rule name is recorded as the reason.
Use case: “Flag for review when a high-value order comes from a Risk-segment customer.”
Require Verification #
Marks the order as needing verification — a “Verify” mark with the rule name appears next to the order’s badge in the WooCommerce orders list — and puts the order on hold with the note “TrustLens: Order held for verification by automation rule …”. If the order is already on-hold, cancelled, refunded or failed, only the mark and a note are added.
TrustLens doesn’t contact the customer or run a verification step itself. Verify them your own way, then move the order on (e.g. to processing).
Action value: not used.
Use case: “Require verification on first orders that ship to a country that doesn’t match the billing country.”
Constraint: Order-bearing trigger only — the rule must have access to an order (order_placed, order_completed, refund_processed, or dispute_recorded). On Order Placed, the hold waits for the payment — see Orders Awaiting Payment above.
One Action per Rule #
A rule has a single action. To do several things on the same event, create one rule per action with the same trigger and conditions:
- Rule A: Add Tag
- Rule B: Hold Order
- Rule C: Send Email Notification
- Rule D: Send Webhook
Rules are independent — if one fails, the others still run. Each rule’s inspector shows its own result.
When Actions Run #
Every action except Send Webhook runs immediately, inside the request that fired the trigger, and isn’t retried. Send Webhook is different:
- The delivery is queued as an Action Scheduler job and logged as QUEUED
- Job runs in the background; the triggering event doesn’t wait
- If the receiver doesn’t answer with a 2xx (error status, timeout, network error), the job is rescheduled with backoff
- Backoff sequence: 60s → 120s → 240s
- After 3 failed retries (4 attempts in all), the delivery is logged as failed and stops retrying
This makes webhooks resilient to transient failures — webhook receivers under temporary load get retried. See Async Dispatch & Retries.
Failure Handling #
Failed actions show as ERR in the Rule Inspector with the failure reason. Common failure modes:
- Webhook error response — any non-2xx status (redirects aren’t followed), retried until the limit is reached
- Webhook timeout — 10-second timeout per attempt
- Invalid webhook URL — the action value isn’t a usable URL
- Order action without an order — e.g. a Dispute Recorded event whose order can’t be loaded: “Action requires an order trigger (Order Placed, Order Completed, Refund Processed, or Dispute Recorded).”
- Unexpected errors — any error thrown while the action runs is logged with its message
Some problems aren’t reported as errors: email delivery failures, and Send Email, Add Admin Note or Add Tag on a customer with no TrustLens record (the run is logged but nothing happens). Customer-level actions on a guest order with no billing email are skipped with “Guest order: no customer email hash”.
Review the Rule Inspector periodically to catch failing actions.
Action Idempotency #
Most actions are idempotent — running them twice produces the same end state. Block, Allowlist, Add Tag, Remove Tag and Hold Order are idempotent (Block and Add Admin Note do append a new note each time). Send Email and Send Webhook are not — each invocation produces a separate side effect. The built-in one-hour cooldown per rule per customer limits duplicate emails and webhooks on rapid trigger events.
Updated on October 18, 2026
