Automated WooCommerce Customer Actions in TrustLens: Rules That Run Themselves

The Gap Between Detection and Response

This is the third post in a five-part series on protecting your WooCommerce store while running promotions safely. The first covered chargeback prevention: how to build a system before a dispute arrives. The second covered reading Trust Score Trends: what the dashboard chart is actually telling you. This one is about closing the loop.

TrustLens free is very good at surfacing risk. It runs eight detection modules in the background, scores every customer from 0 to 100, and shows you who is moving toward the Risk or Critical segment. The problem is that surfacing risk and responding to risk are two different things, and the free version requires a human to do the second part.

Manual review works at 30 orders a day. It breaks at 200. It fails entirely when the order that matters most — a $350 purchase from a customer who just slid into Critical — arrives while you are asleep, at a weekend, or in the middle of a flash sale when your attention is already consumed. By the time you see it, it has already been picked, packed, and dispatched.

Automation Rules (a Pro feature) close this gap. You define what TrustLens should do when specific events happen — hold the order, send you an alert, fire a webhook, flag the customer for review. The rules run continuously, apply immediately, and do not depend on anyone watching a dashboard.

What Automation Rules Actually Are (Pro Only)

TrustLens Automation Rules is a trigger-based response engine available exclusively on the Pro plan. It is not enabled by default after upgrading — you need to turn it on in TrustLens Settings and build at least one rule before anything happens. This is intentional: TrustLens has never invented rules for you behind your back, and Pro keeps that promise.

Once enabled, Automation Rules watches for events across your WooCommerce store — orders being placed, disputes being recorded, scores changing, linked accounts appearing — and evaluates each event against your configured rules. When a rule matches, TrustLens runs the action you specified: holding the order, sending you an email, blocking the customer, or firing an outbound webhook to your CRM or helpdesk system.

Every rule you build is visible on the Automation Rules page. You can enable, disable, or edit any rule at any time. An inline inspector shows exactly why each rule fired or did not fire, so if a rule is not behaving as expected, you can diagnose it without guesswork.

The Three-Part Model: Trigger, Conditions, Action

Every TrustLens automation rule has three parts. Understanding how they interact is the key to building rules that fire when you want them to and stay quiet when you don’t.

The most important constraint in the model: some actions require order context. You cannot hold, cancel, or require verification on an order unless the trigger that fires the rule actually carries an order — and only four of the fifteen triggers do (Order Placed, Order Completed, Refund Processed, and Dispute Recorded). This matters for rule design: if you want to hold an order, you must pair it with one of those four triggers.

The 15 Triggers

TrustLens Automation Rules currently ships with fifteen triggers. They fall into four natural groups based on the kind of event they represent.

Risk signal triggers (no order context)

These fire when TrustLens detects a change in a customer’s trust profile. They are the broadest triggers for building notification and early-warning rules.

• Score Updated — fires every time TrustLens recalculates a customer’s trust score. On a busy store this fires frequently; pair it with a trust score condition to avoid noise.
• Segment Changed — fires only when a customer moves to a different segment (e.g. from Caution to Risk). More targeted than Score Updated because it ignores score fluctuations within the same segment.
• Shipping Anomaly — fires when the shipping address module detects unusual patterns: a rapid sequence of different delivery addresses, or addresses whose velocity triggers a flag.
• Linked Accounts Detected — fires when TrustLens finds shared fingerprints across two or more customer accounts, suggesting multi-account abuse.

Order triggers (carry order context)

These four triggers carry the relevant WooCommerce order into the rule evaluation. This means you can read order-specific fields in your conditions (order total, payment method, shipping country, coupon amount) and use order-level actions (hold, cancel, require verification).

• Order Placed — fires immediately when a checkout order is created, before fulfillment begins.
• Order Completed — fires when an order transitions to the “Completed” status.
• Refund Processed — fires when a refund is issued on an order. Useful for escalating after a second or third refund from the same customer.
• Dispute Recorded — fires when a dispute (chargeback or PayPal claim) is ingested by the chargeback tracking module and associated with a specific order.

Financial event triggers (no order context)

• Chargeback Filed — fires when a chargeback is confirmed at the customer level. Unlike Dispute Recorded, this trigger does not carry a specific order, because a chargeback may relate to a period of activity rather than one transaction.
• Card Testing Attack — fires when the Card-Testing Defense module detects an attack at checkout and associates an email address with it.

Customer lifecycle triggers (no order context)

• Checkout Blocked — fires when a customer is turned away at checkout because they are on the block list.
• Customer Blocked — fires when a customer is blocked, whether by a manual admin action or by another automation rule.
• Customer Unblocked — fires when a block is removed.
• Customer Allowlisted — fires when a customer is added to the allowlist.
• Customer Allowlist Removed — fires when a customer is removed from the allowlist.

The 32 Condition Fields

Every rule can have zero or more condition rows. All conditions are ANDed: every row must be true for the rule to fire. An empty conditions list means the rule fires for every event of its trigger type — which is fine for alert rules you want to run unconditionally, but dangerous for blocking or cancelling rules.

Condition fields fall into two groups depending on the trigger.

Customer profile fields (26 fields — available on any trigger)

These read directly from the customer’s TrustLens profile, which is built from their entire order history across all detection modules:

• Trust profile: trust score (0–100), segment (VIP / Trusted / Normal / Caution / Risk / Critical), customer type (guest or registered)
• Order history: total orders, total order value, cancelled orders, days since last order, customer age in days
• Refund history: total refunds, total refund value, full refunds, partial refunds, return rate
• Coupon behavior: total coupons used, first-order coupons used, coupon-then-refund count (orders where a coupon was used and then refunded)
• Dispute history: total disputes, disputes won, disputes lost
• Linked accounts: linked account count
• Admin state: is blocked, is allowlisted, is flagged, order edit count, reviews before refund count, is first order

Order-only fields (6 fields — only available on the 4 order-bearing triggers)

These read from the current order and are only available when the trigger carries order context (Order Placed, Order Completed, Refund Processed, Dispute Recorded):

• Order total (the order’s total value)
• Coupon total (the discount applied by coupons on this order)
• Payment method (the gateway slug used for this order)
• Shipping country (the country in the shipping address)
• Billing country (the country in the billing address)
• Country mismatch (whether the billing and shipping countries differ)

If you try to use an order-only field on a non-order trigger, TrustLens’s save-time validator will catch the contradiction before the rule is saved — these combinations can never match, and the engine does not let you build a rule that silently never fires.

The 10 Actions

Once a trigger fires and all conditions match, TrustLens runs one action. You cannot stack multiple actions on one rule — if you want two things to happen (say, send an email and hold the order), you build two rules with the same trigger and conditions.

What to Automate and What to Keep Manual

The most common mistake with automation rules is treating every action as equally safe to automate. They are not. A misfire from an Add Tag rule costs nothing. A misfire from a Cancel Order rule costs a legitimate sale, the customer relationship, and potentially a chargeback from someone who was charged but did not receive their goods.

A useful mental model is to think of actions in three tiers:

Automate confidently

Add Tag, Add Note, Flag for Review, Send Email, Send Webhook — these actions leave a record or send a notification. None of them stop an order or remove a customer’s ability to shop. If a rule misfires on a good customer, the cost is a slightly cluttered customer profile or an unnecessary email to you. Clean up the note or remove the tag, tighten the rule, and move on.

You can write these rules with relatively loose conditions. A rule that says “flag for review any customer whose segment just changed to Caution” may occasionally flag a customer who has a bad week and then recovers — that is fine, because flagging does not prevent anything.

Automate carefully

Hold Order, Require Verification — these pause the order workflow and require a human to release it. If they misfire on a good customer, you create friction: the customer’s order is delayed, they may contact support, and you need to manually review and release it. The cost is real but recoverable.

Keep conditions tight when using these actions. A rule like “hold any order from a customer with trust score < 50” will catch a lot of legitimate orders from Caution-segment customers who are simply new to your store with not enough history yet. Combine the score condition with something more specific — order total above a threshold, a country mismatch, a coupon-then-refund history — to reduce noise.

Automate deliberately

Block Customer, Cancel Order, Allowlist Customer — these are the highest-impact actions. A block prevents all future purchases. A cancellation ends an existing order irreversibly. An allowlist lock freezes a score at 100 permanently (until manually changed).

For these actions, treat conditions as if a real customer depends on them being right — because they do. Build the rule. Enable it in a monitoring-only mode by running it with Flag for Review first. Watch the inspector to see which customers it would have hit. Once you are satisfied with the signal quality, switch to the real action. Never automate a block or cancel rule without first validating it on live data.

Three Worked Examples

The following examples show rules at three different points on the automation spectrum — from fully safe to act on immediately, to consequential enough to validate first. All three are different from the five rules in the full mechanics guide.

Example 1: Flag for review when linked accounts appear

Linked-account abuse — multiple customer identities sharing fingerprints to claim repeat first-order discounts — is one of the harder patterns to catch manually. TrustLens detects it when fingerprints overlap. This rule puts a soft marker on any customer where that detection fires, so you know to look at their profile before their next order ships.

• Trigger: Linked Accounts Detected
• Condition: Linked Accounts > 1
• Action: Flag for Review

The condition “linked accounts > 1” means the system found at least two accounts linked to this customer. With the 1.3.8 update, TrustLens requires a stronger shared signal (shared address, phone, or payment method) before creating a link — shared browsers and IP addresses alone no longer create false links. This means the Linked Accounts Detected trigger is already filtered for meaningful signal before your rule even evaluates.

This is a low-risk rule to enable immediately. Flagging does not block anyone. It adds a visible marker to the customer list that prompts a manual look before shipping. You can unflag anyone it hits incorrectly in one click.

Example 2: Send an email when a customer enters the Risk segment

A customer moving into the Risk segment (trust score 10–29) is meaningful news: TrustLens has accumulated enough negative signals to class them as genuinely problematic. This rule sends you an alert the moment that transition happens, so you can look at the profile before their next order arrives — not after.

• Trigger: Segment Changed
• Conditions: Segment = Risk; Total Orders ≥ 3
• Action: Send Email

The “total orders ≥ 3” condition filters out customers who entered Risk on very limited data — a new customer who had one bad refund might briefly land in a risk segment while the system still has too little information to be confident. Waiting until 3 orders ensures the score is grounded in real behavior.

This rule is a notification, not an intervention. It fires, sends you an email with the customer’s score and profile link, and leaves all decisions to you. Safe to enable on day one.

Example 3: Hold a large order from a low-trust customer

This rule targets the scenario that most concerns store operators: a significant order placed by someone whose trust profile is already weak. Holding the order gives you a window to manually review it before fulfillment begins.

• Trigger: Order Placed
• Conditions: Trust Score < 40; Order Total > 150
• Action: Hold Order

The dollar threshold is yours to calibrate for your store. A store selling $15 accessories might use $80. A store selling electronics might use $400. The trust score threshold of 40 puts the filter in the lower half of the Normal segment and below — catching Caution and Risk customers, not just Critical ones.

Because this rule uses the Hold Order action (which requires an order-bearing trigger), it only works with Order Placed, Order Completed, Refund Processed, or Dispute Recorded. The combination of trust score and order total as conditions is tight enough to avoid holding most legitimate orders, but broad enough to catch the scenarios that lead to chargebacks.

Before enabling this rule with the Hold Order action, run it with Flag for Review first. Watch the customer list for a week to see who it is flagging. If you are satisfied with the quality of what it catches, switch the action to Hold Order.

The Cooldown: Why the Same Rule Doesn’t Fire Twice in an Hour

Every automation rule has a built-in cooldown. By default, once a rule fires for a specific customer, the same rule will not fire again for that customer for one hour. After the hour expires, the rule is eligible to fire again.

The cooldown exists for two reasons. First, some triggers fire in bursts. If you batch-process a customer’s orders and each one triggers a score update, Score Updated can fire several times in a few minutes. Without a cooldown, a Send Email rule would fill your inbox. Second, some actions create their own triggers — a Block Customer action fires the Customer Blocked trigger, which could re-evaluate block-related rules in a loop. The cooldown prevents that recursion.

The cooldown is keyed to the rule and the customer together. Rule A cooling down for Customer X does not affect Rule B, and it does not affect Rule A for Customer Y. If you have two different rules on the same trigger, they each have their own independent cooldown.

If an action fails (an SMTP connection drops, a webhook returns a 5xx error), TrustLens releases the cooldown so the next event can retry. A transient failure does not silence the rule indefinitely.

The Validator and the Inspector

Two tools protect you from rules that look right but never actually fire.

The save-time validator runs every time you save a rule. It checks for conditions that can never be satisfied — logical contradictions like “trust score > 80 and trust score < 30”, values outside a field’s valid range, order-only fields paired with non-order triggers, and trigger-state contradictions (asking whether a customer is blocked on the Customer Unblocked trigger, where they are guaranteed to not be). If the validator finds a problem, it blocks the save and explains what is wrong. This means you cannot accidentally build a rule that sits enabled and silently never fires.

The inline inspector runs on live data. For every rule evaluation, TrustLens logs whether the rule fired (action was taken), was skipped (conditions did not match, with the specific failing condition recorded), or errored (the action failed). You can read this log from the Automation Rules page. If you have built a rule and it is not firing when you expect it to, the inspector will tell you exactly which condition blocked it for each specific customer. For a deeper look at both tools, including the full mechanics of how the rule engine evaluates conditions, the complete automation mechanics guide covers them in detail.

Free vs Pro

TrustLens free gives you complete visibility into customer risk — all eight detection modules running, the full 0–100 trust score, six segments, every signal visible on the customer profile. What it does not give you is automatic responses. Every action in the free version requires a human to initiate it: you open a customer profile, you decide to block them, you click the block button. The guide to what TrustLens actually does walks through every detection module and what the free version surfaces.

Pro adds Automation Rules, which removes the human-in-the-loop requirement for the responses you want to automate. It also adds the Advanced Chargeback Monitor (per-brand dispute ratios, 12-month trends, a deadline worklist, and Dispute Evidence Reports), Card-Testing Defense Pro (auto-escalation, geo-diversity safeguard, attack analytics, and Slack alerts), Payment Method Risk Controls, and Scheduled Reports.

If your store is large enough that manual review of every risk signal is unsustainable, or if the timing of fraudulent orders consistently beats your working hours, Automation Rules is the feature that changes that. If you are still at a scale where you can realistically review every flagged customer before their next order ships, the free version may be enough for where you are today.

Common Questions

Can a rule fire on a guest order?

Yes, with a limitation. Guest orders are identified by an email hash. If a guest customer has no prior order history in TrustLens (which is common for genuinely new guests), conditions that read customer profile fields — trust score, segment, total orders — will fail to match because there is no profile yet. Conditions that read only from the order itself (order total, payment method, shipping country) will still work. TrustLens logs a clear “skipped” row for guest orders where customer-backed conditions could not be evaluated, so the inspector explains what happened.

What happens to a rule when a customer is on the allowlist?

Rules still evaluate — TrustLens does not automatically suppress all rules for allowlisted customers. Whether the rule fires depends entirely on your conditions. If you want to prevent rules from taking negative action on VIP customers, add a condition “Is Allowlisted = No” to any block, cancel, or hold rules. The allowlist protection in TrustLens free locks the score at 100 and prevents scoring modules from lowering it; it is not a blanket rule bypass.

How many rules can I have?

There is no hard limit enforced by TrustLens. Practically, more rules mean more evaluations on every event. The evaluation is fast — rules load from an in-memory cache keyed by trigger — but very large rule sets on a very high-traffic store are worth monitoring. Start with a focused set of rules for your highest-value scenarios rather than trying to cover every possible pattern from day one.

Can automation rules be paused without deleting them?

Yes. Each rule has an enabled/disabled toggle. Disabling a rule stops it from evaluating on new events; it does not delete the rule or its historical log. You can re-enable it at any time. This is useful when you are testing a new rule configuration or temporarily suspending a rule during a sale where its conditions would be too noisy.

Does a webhook retry keep the original action log entry?

TrustLens logs a “queued” status row when a webhook is handed to Action Scheduler, and updates it to “ok” or “error” when the delivery resolves. Retries do not create duplicate log rows — the terminal outcome of the delivery chain (success or exhausted retries) is the single logged result. If a delivery ultimately fails after all three retries, the log records the final HTTP status and error message so you can diagnose the endpoint.

What does the chargeback prevention series cover?

This post is the third in a five-part series. The chargeback prevention playbook covers how to read the signals before a dispute arrives. The Trust Score Trends guide covers reading your store’s daily average score to catch patterns early. This post covers Automation Rules. The fourth post will cover bulk discounts and tiered pricing in WooCommerce, and the fifth will cover running promotions without attracting fraud — how Smart Cycle Discounts and TrustLens work together.

TrustLens is available on the Webstepper plugin page; the free version (with all eight detection modules and full trust scoring) is on the WordPress plugin repository. Automation Rules, along with the Advanced Chargeback Monitor and the Dispute Evidence Reports, are part of the Pro plan. If you are starting from scratch and want to understand what TrustLens builds before you automate responses to it, the guide to what TrustLens actually does is the right place to begin.