TrustLens Pro Automation Rules: A Practical Playbook With Five Rules to Build First

There’s a gap that quietly costs stores money: the gap between seeing a risk and acting on it in time. TrustLens free is built to close the first half — it scores every customer from 0 to 100, sorts them into six segments, and shows you exactly which behaviors moved each score. But seeing a customer slide into the Risk segment at 11pm doesn’t help if nobody’s looking at the dashboard until Monday, and the fraudulent order has already shipped.

Automation Rules (a Pro feature) close the second half. They watch for the events you’d otherwise have to catch by hand — an order placed, a dispute recorded, a card-testing attack, a set of linked accounts surfacing — and take the action you’d have taken yourself, immediately, every time, without you being awake for it.

But here’s the catch nobody tells you: automation rules do nothing until you design them. The feature ships as an empty canvas. That’s correct behavior — TrustLens free deliberately never auto-blocks anyone behind your back, and Pro keeps that promise by never inventing rules for you. But it means the first time you open the Automation Rules page, you’re staring at a blank screen with no idea what a good rule looks like.

This playbook fixes that. Five rules, drawn from the fraud patterns that show up again and again in real WooCommerce stores. For each one you’ll get the exact trigger, the condition fields to set, the action, and a cooldown recommendation. Build these five and you’ll have a working automation layer in an afternoon — then you can adapt them to your own store from a known-good starting point instead of a blank one.

Why automation rules matter

Manual review works right up until it doesn’t. A store doing 30 orders a day can eyeball flagged customers. A store doing 300 can’t — and the orders that matter most (high-value, high-risk) tend to arrive at the worst times: overnight, during a flash sale, in the middle of a card-testing burst when your attention is already split.

The cost of the gap isn’t abstract. A serial returner who slips through for another month. A second chargeback that pushes your ratio closer to a Visa or Mastercard monitoring program. A stolen-card order that ships before you wake up. None of these are failures of detection — TrustLens saw all of them. They’re failures of timing. Automation rules are how you make the response as fast as the detection.

The anatomy of a rule

Every TrustLens automation rule is three parts plus a guardrail. The short version is below; for every field and option, the TrustLens docs keep the full triggers reference, conditions reference, and actions reference.

• Trigger — the event that wakes the rule up. The rule editor offers fifteen, in four groups: trust signals such as Score Updated and Segment Changed; order events (Order Placed, Order Completed, Refund Processed, Dispute Recorded); fraud signals such as Linked Accounts Detected and Card Testing Attack; and customer status changes such as Customer Blocked.
• Conditions — the tests the customer or order has to pass before the rule acts. There are more than 40 condition fields, covering the customer’s history (trust score, segment, refunds, disputes, linked accounts, customer age), the order in front of you (order total, coupon total, payment method, countries, country mismatch) and, on Refund Processed only, the refund itself. Number fields take the usual comparisons; text and yes/no fields take only equals or not equals.
• Action — what the rule does when every condition passes. There are eleven. Eight work with any trigger: Send Email Notification, Add Admin Note, Add Tag, Remove Tag, Block Customer, Allowlist Customer, Flag for Review, and Send Webhook. Three act on the order itself, so they only pair with an order event: Hold Order, Cancel Order, and Require Verification.
• Cooldown — the guardrail. Once a rule has acted on a customer, the same rule won’t act on that customer again for an hour, so a burst of events doesn’t send you ten identical alerts. When a rule skips because of it, the inspector says so explicitly.

That’s the whole model. Trigger, conditions, action, cooldown. Every rule below is just a specific filling-in of those four slots.

How a rule is evaluated

When an event fires, TrustLens checks every enabled rule attached to that trigger, each on its own — rules sharing a trigger don’t override one another, and every one whose conditions pass will act. Conditions combine with AND only and are checked in order; the first one that fails ends the evaluation and becomes the reason the inspector records. There is no OR, so to act when either A or B is true, build two rules with the same action. When every condition passes, the action runs: order actions on the order that arrived with the event, customer actions on the customer’s record after a cooldown check. Ran, skipped, or failed, every evaluation leaves a row in the log.

Three details catch most first-time builders:

• There are two switches, not one. Each rule has its own “Rule is active” toggle, but nothing fires until the engine itself is on — the “Engine running” toggle at the top of the Automation screen, which starts switched off.
• Values must match exactly. Segment values are the lowercase keys (vip, trusted, normal, caution, risk, critical), so Segment = Critical saves but never matches. Yes/no fields take 1 for yes and 0 for no.
• Lifetime is not this order. Total Order Value is everything the customer has ever spent with you; the size of the order in front of you is Order Total, which, like every order field, the editor only accepts on the four order events.

The cooldown window, and how to work with it

The cooldown is keyed to one rule and one customer: when a rule acts on a customer, that rule is suppressed for that customer for one hour, while other customers can still trigger it and other rules can still act on the same customer. It matters most on chatty triggers — Score Updated fires on every recalculation of a customer’s score.

• It only throttles customer actions. Hold Order, Cancel Order, and Require Verification act on an order and are never held back, so every qualifying order is handled. Order Placed fires once per order (a retried payment doesn’t fire it again), so the same order isn’t processed twice.
• The editor has no cooldown field. One hour is the default for every rule. A developer can change it with the trustlens/automation/rule_cooldown filter, which receives the rule being evaluated, so different rules can get different windows; returning 0 switches it off.
• For one-shot actions, add a state condition. A rule that blocks or allowlists would otherwise match again once the hour is up. Adding Is Blocked = 0 (or Is Allowlisted = 0) makes it stop matching the moment the job is done — Rules 1 and 5 below do exactly this. And when you’re testing, a “Cooldown active” skip just means you need to wait out the hour or use a different customer.

Rule 1 — Block after a second lost dispute

The pattern: a customer files a chargeback, you lose it, and then it happens again. One lost dispute can be a genuine grievance or a confused buyer. A second lost dispute from the same customer is a different signal — it’s the strongest leading indicator of someone you should not be selling to, and every additional dispute drags your store-wide ratio toward a card-network monitoring program.

Why not Dispute Recorded? That trigger fires when a dispute is opened, before you know the outcome, and Total Disputes counts every dispute filed. A loss is recorded later, and TrustLens then recalculates the customer’s score — which fires Score Updated, so this rule acts on the second loss itself. To act sooner, on a second dispute being opened, use Dispute Recorded with Total Disputes ≥ 2 instead, knowing some of those may still go your way.

This is one place where TrustLens Pro also offers a dedicated, non-rule path: the Advanced Chargeback Monitor includes an auto-block after lost disputes setting (off by default) that blocks a customer once they reach the number of lost disputes you choose, without you building a rule at all. Use whichever fits your mental model — the automation rule gives you more control over the conditions; the built-in setting is a single number. If you want the background on where dispute data comes from in the first place, TrustLens ingests chargebacks from Stripe and WooPayments automatically, which is what keeps the dispute counts — and this rule — current without manual entry.

Rule 2 — Hold large orders from Caution-and-below customers

The pattern: a customer whose behavior has already pushed them into the Caution, Risk, or Critical segment places an unusually large order. The order value is what makes this worth a manual look — a $20 order from a shaky customer isn’t worth your time; a $400 one is. Holding (rather than blocking or cancelling) is the right reflex here: you’re not accusing anyone, you’re just buying yourself the chance to glance at the order before it fulfills.

Under the default segment thresholds, Caution, Risk, and Critical are exactly the scores below 50 — and since conditions can’t be OR-ed, one trust-score test does the job of three segment rules.

Tune the $150 threshold to your store. The right number is roughly your average order value plus a margin — high enough that normal orders sail through, low enough that the orders worth a second look get caught. If you find yourself releasing nearly every held order, the threshold is too low or the segment net is too wide. This is the graduated-response philosophy in a single rule: rather than blocking outright, you can hold high-risk orders without blocking good customers and keep the human in the loop for the borderline cases. Before relying on it, place a matching test order through your own payment gateway and confirm it’s still on hold once payment has gone through.

Rule 3 — Alert the moment a Critical customer orders

The pattern: you have a small number of customers who’ve earned their way into the Critical segment — the worst 0–9 band of the trust score. You’re not necessarily ready to auto-block them (maybe they have legitimate orders mixed in, maybe you want eyes on it first), but you absolutely want to know the instant one of them places an order, so you can decide in minutes instead of finding out days later.

Two accuracy notes worth being precise about. First, TrustLens automation rules deliver alerts through Send Email Notification (the email names the rule and customer, with their trust score, segment, and a profile link) and Send Webhook. Slack needs one extra hop: its incoming webhooks expect a message text field, while TrustLens posts structured JSON (rule, trigger, trust score, segment), so point Send Webhook at a tool such as Zapier or Make, or a small endpoint of your own, that turns the payload into a Slack message. (Outgoing webhooks are HMAC-SHA256 signed by default and delivered in the background with automatic retry, so a momentary network blip doesn’t lose the alert.) Second: alerting is non-destructive, which makes Rule 3 the safest of the five to turn on first. Nothing gets blocked, held, or cancelled — you’re simply wiring up a tripwire.

Rule 4 — Cancel country-mismatch orders below trust 40

The pattern: an order arrives where the billing country and the shipping country don’t match, and the customer’s trust score is already low. Country mismatch on its own is a weak signal — plenty of legitimate people ship gifts abroad or travel. But country mismatch combined with a sub-40 trust score is a much stronger one, and it’s a classic shape for stolen-card and reshipping fraud. This is the one rule in the playbook aggressive enough to cancel rather than hold — and only because the two conditions together are specific enough to justify it.

Country Mismatch is only true when the order has a shipping country that differs from billing; an order with no shipping country (a digital download, say) never counts.

Rule 5 — Allowlist your VIPs so rules never touch them

The pattern is the inverse of the others: protect your best customers from your own automation. Your highest-value, longest-tenured buyers occasionally do things that look superficially risky — a large order, a return, a shipment to a second address. You never want a fraud rule to hold or cancel an order from someone who’s spent thousands with you over three years. Allowlisting pins a customer’s score at 100 in the VIP segment and stops negative signals from moving it, so Rules 2, 3, and 4 can’t match them — and checkout enforcement skips allowlisted customers, so even a Rule 1 block wouldn’t stop them.

A word of caution on this one, because it’s the rule most worth thinking twice about. Allowlisting is a strong, semi-permanent grant of trust — an allowlisted customer’s score is pinned at 100 and stops responding to behavior, so if one of your VIPs ever does go bad, the system won’t catch it until you manually remove them from the allowlist. Many stores prefer to allowlist VIPs by hand, deliberately, rather than automate it across an entire segment. If you do automate it, keep the condition tight (VIP only, never Trusted) and review your allowlist periodically.

The validator and the inspector — your two safety nets

Two features make building rules far less nerve-wracking than it sounds, and they’re the reason a playbook like this is safe to follow. Both are confirmed parts of TrustLens Pro’s automation system.

The save-time validator

When you save a rule, TrustLens checks it before it ever goes live and blocks rules that can never fire. It catches unsatisfiable conditions, schema violations, trigger-state contradictions, invalid operators for a field type, and incomplete actions — and it tells you the specific reason inline, right next to the rule, rather than letting you publish something that silently does nothing. In practice, it refuses rules like these:

• Impossible comparisons — “greater than” on Segment, or Trust Score above 100.
• Conditions that cancel out — Trust Score above 80 and below 30, or Is Blocked = 0 on the Customer Blocked trigger, which only fires once the customer is blocked.
• A trigger that can’t supply what the rule needs — Hold Order or an Order Total condition on a trigger that carries no order; refund fields outside Refund Processed.
• An action missing its input — Send Webhook without a valid URL, a tag action without a tag name, or an email recipient that isn’t an address.

This matters more than it first appears. The most dangerous automation bug isn’t a rule that does the wrong thing — it’s a rule you believe is protecting you that is actually a no-op. A condition that contradicts its own trigger, a comparison that can never be true: the validator catches these at save time, so you never get the false confidence of a rule that looks active on the list but never actually runs.

What it can’t know is whether a legal-looking value will ever occur — Segment = Critical with a capital C is a valid comparison, so it saves, and then never matches. That’s the gap the inspector covers.

The inline rule inspector

The inspector answers the single most common question store owners ask about any automation system: “why didn’t my rule fire?” For each evaluation, it records whether the rule ran or skipped — and when it skipped, it gives the exact reason. You’ll see entries like Cooldown active or Condition not met: trust_score > 50, so instead of guessing, you can read precisely why a given order didn’t trigger the action you expected.

Each rule’s panel shows its fire, success, error, and skip counts plus its ten most recent runs, each badged OK, SKIP, ERR, or QUEUED, with the reason under any skip or error. QUEUED is specific to webhooks: every other action runs as soon as the rule matches, but a webhook is handed to Action Scheduler (WooCommerce’s own background queue), with identical deliveries in a burst collapsed into one. If the receiver doesn’t answer with a success code, TrustLens retries three times — after one, two, and four minutes — and the outcome lands as a separate OK or ERR run, with the HTTP status or connection error on failure.

In practice, the inspector is how you tune every rule in this playbook. Build the rule, let it run against real traffic, then read the inspector to see what it’s selecting and skipping. If Rule 2 is holding orders you’d rather let through, the inspector shows you which condition let them in. If Rule 4 never fires, the inspector tells you whether it’s the country-mismatch test or the trust-score test that’s filtering everything out. It turns rule-tuning from guesswork into reading a log.

What’s free vs Pro

To be completely clear about the line, since this whole playbook lives on the Pro side:

The mental model TrustLens is built around: free surfaces the risk; Pro acts on it. If you’re still on free and doing manual review, that’s a legitimate place to operate from — plenty of smaller stores never need automation. The moment manual review starts losing the race against your order volume is the moment this playbook earns its keep.

Common questions

Will building these rules block legitimate customers?

Only if you configure them to, and only after you enable them. Rules 2, 3, and 5 (hold, alert, allowlist) take no destructive action at all, and neither does Rule 4 if you run it as a hold first. The two that can block or cancel (Rules 1 and 4) are deliberately conservative: a second lost dispute, or a country mismatch combined with a sub-40 trust score. The recommended path is to watch every rule in the inspector before trusting it, and to run the sharpest rules as holds until your own data proves they should escalate.

What’s the difference between hold, cancel, and block?

Hold pauses a single order for manual review — the customer is unaffected and you decide. Cancel cancels that one order outright. Block acts on the customer, not the order — with Enable Blocking switched on in Settings, it stops that email from adding to cart or checking out on future visits, until you unblock them. As a rule of thumb: hold when you want a human to look, cancel when the order itself is clearly bad, block when the customer is the problem.

How do I send alerts to Slack specifically?

Use the Send Webhook action with a go-between: Slack’s incoming webhooks expect a message text field that TrustLens’s structured JSON payload doesn’t carry, so send it to Zapier, Make, or a small endpoint of your own that formats the message for Slack. TrustLens signs, queues, and retries the delivery. (Note: the dedicated Slack/email alert dispatcher built into Card-Testing Defense Pro is a separate feature for card-testing attack events — for general automation-rule alerts, the webhook action is the path.)

Why did my rule not fire?

First check that the engine is running (the toggle at the top of the Automation screen) and the rule itself is active. Then open the inline inspector. It logs every evaluation and, for skipped ones, gives the exact reason — Cooldown active, or Condition not met: followed by the specific condition that failed. If the failing condition looks right, check the value’s spelling and case: segment values are lowercase (critical, not Critical), and yes/no fields take 1 or 0. If a rule won’t even save, the save-time validator will have told you why inline — usually an unsatisfiable condition or an incomplete action.

Do I need Pro to see risky customers at all?

No. All trust scoring, all six segments, all eight detection modules, the dashboards, the customer profiles, manual blocking and allowlisting, and chargeback tracking with a ratio threshold alert are in the free version. Pro adds the ability to act automatically on what free shows you — automation rules, the validator and inspector, signed webhooks, scheduled reports, the Advanced Chargeback Monitor, and Card-Testing Defense Pro. If you only want to see and decide manually, free is genuinely complete.