How to Use TrustLens Automation Rules to Hold High-Risk Orders Without Blocking Good Customers

The instinct when you spot a high-risk customer is to block them. It is clean, it is immediate, and it feels like you have dealt with the problem. But a hard block is a blunt instrument. It cannot distinguish between a long-standing customer who had a run of refunds during a difficult year and a serial abuser working through their fifth throwaway account. Applied without nuance, it catches both.

TrustLens Pro Automation Rules are designed for the situation in between: you see something that warrants a response, but you are not ready to close the door permanently. Hold the order and review it. Flag the account. Send yourself an alert at midnight when a high-value order from a risky segment arrives. Fire a webhook so your fulfillment system pauses before it ships. These are proportionate responses, and proportionality is what keeps you from accidentally blocking good customers along with bad ones.

This guide covers every part of the Automation Rules system as it exists in TrustLens version 1.2.3: the triggers, the condition fields, the available actions, and how to assemble rules that do what you actually intend.

The Problem With Hard Blocks

A hard block in WooCommerce prevents a customer from completing checkout. It is the right tool for someone you are certain is abusive. But certainty is rarely where you start — you start with a signal.

A customer who returned four orders in three months is concerning, but they might also be going through a difficult period, or your sizing guide might be inaccurate for their preferences. A customer with two linked accounts might be a fraud ring or might be a couple sharing a shipping address. A customer whose trust score just dropped below 40 has triggered multiple negative signals — but you may not have reviewed which ones.

The gap between “signal received” and “I am confident this is abuse” is exactly where a hard block does the most damage. Block too early and you lose a customer who might have been worth keeping. Block too late and the damage is already done. What you need is a response that buys you time: hold the order so it cannot ship while you investigate, flag the account so it shows up in your review queue, alert yourself so you can look at it when you have a moment.

That is what TrustLens Automation Rules make possible. As discussed in the guide on why manual blocking fails, static enforcement does not scale — but graduated, trigger-based enforcement does, precisely because it responds proportionally and automatically.

What TrustLens Automation Rules Are

TrustLens Automation Rules is a trigger-based rules engine built into TrustLens Pro. Each rule has three parts: a trigger (the event that fires the rule), an optional set of conditions (filters that narrow when the rule actually executes), and an action (what happens when the rule runs).

Rules are managed from TrustLens → Automation in the WordPress admin. You can create as many rules as you need, enable or disable them individually, and review an execution log that tells you exactly when each rule fired and why.

Rules run asynchronously in the background. They do not block the checkout or slow the page — they queue work via Action Scheduler, the same background system WooCommerce uses for its own jobs. Actions that involve external delivery (webhooks) are retried automatically up to three times with exponential backoff (60s, 120s, 240s) if the first attempt fails.

The 15 Triggers — What Fires a Rule

A trigger is the event that causes TrustLens to evaluate whether a rule should run. When a trigger fires, TrustLens checks all enabled rules registered to that trigger, evaluates their conditions, and executes matching rules’ actions.

TrustLens Automation Rules supports 15 triggers, falling into three broad categories.

Customer risk triggers

These fire when a customer’s risk profile changes in a way TrustLens has measured.

• Score Updated — fires every time a customer’s trust score is recalculated, whether it went up or down. Useful for rules that watch a numeric threshold (“notify me when any customer’s score drops below 30”).
• Segment Changed — fires only when the customer’s segment actually transitions to a new value. More selective than Score Updated: it will not fire repeatedly just because the score oscillates within the same segment band. Use this for rules keyed to segment transitions (“when a customer moves to Risk or Critical, hold their next order”).
• Customer Blocked — fires when a customer’s checkout access is removed, whether by a rule or manually.
• Customer Unblocked — fires when a block is lifted.
• Customer Allowlisted — fires when a customer is added to the allowlist (score locked at 100, immune to negative signals).
• Customer Allowlist Removed — fires when an allowlist entry is cleared.

Order and transaction triggers

These fire when a specific order event occurs. They carry the order object into the rule, which unlocks order-level conditions and order-level actions.

• Order Placed — fires when a customer completes checkout and an order is created.
• Order Completed — fires when an order transitions to the Completed status.
• Refund Processed — fires when any refund is issued against an order.
• Dispute Recorded — fires when a dispute is logged against a specific order (Stripe or WooPayments automatic ingestion, or manual entry). Carries order context, so you can pair it with order-level conditions like the order total.
• Chargeback Filed — fires at the customer level when a chargeback is confirmed. No specific order is attached; use Dispute Recorded if you need to act on the specific order.
• Checkout Blocked — fires when a blocked customer attempts checkout and is prevented from completing it.

Fraud signal triggers

These fire when TrustLens detection modules identify a specific fraud pattern, independent of any order event.

• Linked Accounts Detected — fires when TrustLens identifies that a customer shares fingerprints (shipping address, billing address, phone, IP, payment method, or device) with other customer accounts.
• Card Testing Attack — fires when a card-testing attack is detected at checkout that can be attributed to a specific customer email. Attacks from devices with no associated email do not route to this trigger.
• Shipping Anomaly — fires when the Shipping Address Anomalies module detects unusual address behavior for a customer (address hopping, billing/shipping country mismatches, address change velocity).

The 22 Condition Fields — How Rules Get Specific

Conditions are optional filters that narrow when a rule actually executes. A rule with no conditions fires for every customer who hits the trigger. A rule with conditions only fires when all conditions evaluate to true.

All conditions within a single rule use AND logic: every condition must be satisfied. If you need OR logic, create separate rules — one per branch.

Customer-level condition fields

These read from the customer’s behavioral record and are available on any trigger.

Order-level condition fields

These read from the order context and are only available on order-bearing triggers (Order Placed, Order Completed, Refund Processed, Dispute Recorded).

How the save-time validator works

TrustLens validates your rule before saving it. If the conditions you have written can never simultaneously be true — for example, requiring a trust score both above 80 and below 30, or requiring a customer to be on their first order and also have more than 10 total orders — the save is blocked with an explanation of exactly which condition is impossible. You will not end up with a rule sitting silently in your automation list that can never fire.

The validator also catches trigger-state contradictions: if your trigger is Customer Blocked, a condition requiring is_blocked = false is logically impossible (the trigger guarantees the customer is blocked when it fires), and the validator will tell you that before you save.

The 10 Actions — What a Rule Actually Does

When a rule’s conditions all pass, one action executes. TrustLens Automation Rules supports 10 actions. Some are customer-level (they affect the customer’s profile or notify you). Three are order-level and can only be used with order-bearing triggers.

Customer-level actions

• Block Customer — prevents the customer from adding items to cart or completing checkout. Works on both Classic and Blocks/Store API checkout. The block reason can be set in the action value field, or it defaults to “Automated: Rule triggered.” The block is reversible at any time from the customer profile.
• Allowlist Customer — locks the customer’s trust score at 100 and prevents any negative signals from affecting it. Use this for rules that confirm a customer is safe — for example, after manual review clears a suspected false positive.
• Flag for Review — adds the customer to your watch list by appending a timestamped note to their admin notes. The dashboard’s watch view surfaces these entries. This is the softest response: it does not restrict the customer at all, but it surfaces them for human attention.
• Send Email — sends an alert email with the customer’s hash, trust score, segment, and a link to their profile. The recipient defaults to your site notification email, but you can set a per-rule override address in the action value field — useful for routing alerts to a specific team inbox.
• Add Note — appends a timestamped note to the customer’s admin notes without adding them to the watch list. Good for logging the reason a rule fired.
• Add Tag — appends a tag entry to the customer’s admin notes. The tag value comes from the action value field. Tags can be used to group customers or to track which rule last acted on them.
• Send Webhook — sends an async HTTP POST to a URL you specify in the action value field. The payload includes the triggering rule’s name and ID, the customer’s email hash, trust score, and segment. Webhooks are HMAC-SHA256 signed (timestamp + body, with an X-TrustLens-Signature header) and retried up to 3 times with exponential backoff on failure.

Order-level actions (require order-bearing triggers)

• Hold Order — transitions the specific order to WooCommerce’s “on-hold” status with a note: “TrustLens: Automation rule triggered — order held for review.” The customer receives the standard on-hold notification. The order stays in your queue for manual review before you decide whether to process or cancel it.
• Cancel Order — cancels the specific order immediately, with a note naming the rule that triggered the cancellation. Use this for high-confidence signals where the policy is clear: certain payment method + known fraud profile = automatic cancellation.
• Require Verification — marks the order with _trustlens_requires_verification order meta and adds an order note. This is a signal for your team to follow up — the order is not automatically put on hold, but the flag shows up in the order notes and can be detected by any system reading TrustLens order meta.

Graduated Response in Practice: Four Example Rules

The value of a rules engine is not having one master rule that tries to do everything. It is having several specific rules, each calibrated to a different risk signal and matched to an appropriate response. Here are four patterns that reflect how the system is typically used.

Rule 1: Hold new orders from Risk-segment customers

This is the most common starting rule, and often the first one stores configure.

• Trigger: Order Placed
• Conditions: segment = Risk
• Action: Hold Order

When a customer in the Risk segment places an order, it goes to on-hold automatically. You review it before it ships. If everything looks legitimate — the product is low-value, the address matches their profile, there is nothing unusual about the payment — you process it. If something looks off, you cancel it and note why. The customer is not blocked; you have simply bought yourself a review window.

Rule 2: Alert on high-value orders from Caution-segment customers

Caution is a softer signal — something has moved this customer’s score down but not dramatically. You might not want to hold every order from a Caution customer, but a high-value order from one warrants a look.

• Trigger: Order Placed
• Conditions: segment = Caution AND order_total >= 150
• Action: Send Email

You get an email with the customer’s profile link. You review it when you have a moment. The order processes normally unless you intervene. This is a monitoring rule, not an enforcement rule — appropriate for the signal level.

Rule 3: Flag accounts when linked accounts are detected

Linked account detection is a signal that multiple accounts share identifying information. It does not definitively mean fraud — it might be a household — but it warrants attention, especially if the linked accounts include profiles already in the Risk or Critical segment.

• Trigger: Linked Accounts Detected
• Conditions: linked_accounts >= 2
• Action: Flag for Review

The customer appears in your watch list. You review their profile and the linked accounts. If the links look innocent, you clear the flag. If they suggest a coordinated abuse pattern — same address, multiple first-order coupon uses across accounts — you escalate.

Rule 4: Block Critical-segment customers immediately

Some stores reserve automatic blocking for the Critical segment only — customers whose scores have reached a point where the behavioral evidence is strong enough to justify a hard enforcement action without manual review.

• Trigger: Segment Changed
• Conditions: segment = Critical
• Action: Block Customer

A customer moving into Critical will be blocked from checkout automatically, at any time of day, without anyone needing to log in and do it manually. Combined with linked accounts detection, this means that when one account in a fraud ring hits Critical, you can configure additional rules to surface the linked profiles for review.

The Rule Inspector: Why a Rule Fired or Didn’t

One of the most frustrating experiences with any automation system is not knowing why something happened or didn’t happen. TrustLens addresses this directly through the rule inspector.

Every time a rule is evaluated — whether it fires or not — TrustLens writes a log row. If the rule fired and the action succeeded, the row shows a status of ok with the duration. If the action failed (an email could not be sent, a webhook returned a non-2xx response), the row shows error with the specific error message. If the rule evaluated but conditions were not met, the row shows skipped with the exact condition that failed: “Condition not met: trust_score > 50” or “Cooldown active.”

This means you can always answer the question “why didn’t my rule fire?” by looking at the inspector for the relevant rule and customer. You do not have to guess at operator precedence or wonder whether your condition values are interpreted the way you expected.

The same log covers guest order behavior. If a rule did not fire because the order was a guest checkout with no email hash to route to a customer record, the log row says “Guest order: no customer email hash.” The inspector tells you what happened so you can adjust the rule rather than assume it is working when it is not. This is a significant improvement over the kind of manual blocking that leaves you no audit trail at all — a subject explored in depth in why manual enforcement breaks down.

Protecting Good Customers from False Positives

Any enforcement system creates false positives eventually. A loyal customer who went through a difficult year and returned more than usual. A long-standing account that happens to share an IP with a family member who turned out to be abusive. The question is not whether false positives happen — they do — but whether you have the tools to catch and correct them.

The allowlist

TrustLens’s allowlist locks a customer’s score at 100 and prevents any negative signals from affecting it. An allowlisted customer will not trigger rules based on trust score or segment thresholds. If you have a VIP customer whose behavioral data has accumulated some noise — returns for legitimate reasons, a linked account that is genuinely innocent — the allowlist is how you protect them from being caught by rules calibrated for genuinely risky behavior.

You can allowlist customers manually from their profile page, or you can create an automation rule that allowlists automatically — for example, an Allowlist Customer action on Order Completed with conditions requiring 50+ total orders and a trust score above 75. That rule would identify your most established loyal customers and mark them as protected without requiring you to find them manually.

The Hold Order approach as protection

Using Hold Order rather than Block Customer for initial enforcement is itself a form of false-positive protection. A held order gives you the opportunity to review before you act. A blocked customer, by contrast, cannot shop with you until someone unblocks them — and if they were a legitimate customer, that experience damages the relationship.

Design your rules so that the more reversible actions fire first. Hold before you cancel. Flag before you block. Block before you make any communication that implies the customer is being accused of fraud.

Building in a segment buffer

Consider using segment = Critical rather than segment = Risk as the trigger for your hardest automatic actions. The Critical segment requires a more severe and sustained behavioral pattern than Risk. Restricting automatic hard enforcement to Critical customers and using softer responses (hold, flag, alert) for Risk customers gives you a meaningful buffer between “concerning” and “confident.”

This is especially valuable for stores with generous return policies, where some level of return activity is expected and normal. A customer in the Risk segment might simply be someone who shops frequently and returns occasionally — not someone who is deliberately exploiting you. The Critical segment is where the pattern becomes harder to explain innocently. For more on how to read customer profile signals, the guide on reading TrustLens customer profiles covers the signal breakdown in depth.

Where to Start If You’ve Never Set Up a Rule

If you are setting up TrustLens Automation Rules for the first time, a staged approach reduces the risk of misconfiguration causing problems before you understand how the system behaves.

Frequently Asked Questions

Do automation rules affect guest checkouts?

Customer-level actions — block customer, add tag, send email — require a customer record to act on. Guest checkouts that have no associated customer email hash in TrustLens will have customer-level actions skipped, and the rule log will record the reason as “Guest order: no customer email hash.” Order-level actions (hold order, cancel order, require verification) can still fire on guest orders because they act on the order object rather than a customer profile.

Can a rule fire more than once for the same customer?

Yes, but the default per-customer cooldown window of one hour prevents rapid repeat fires. If the same trigger fires multiple times for the same customer within an hour of the previous rule execution, the rule is skipped and the log records “Cooldown active.” After the cooldown window expires, the rule is eligible to fire again. The cooldown window can be adjusted via the trustlens/automation/rule_cooldown WordPress filter.

What happens if the action fails — for example, a webhook times out?

Webhook delivery failures are retried automatically up to three times: after 60 seconds, then 120 seconds, then 240 seconds. If all three attempts fail, the rule log records the final error. Email send failures are logged with the PHP mail error when available. Failed actions release the cooldown so the next trigger event for that customer can retry, rather than being suppressed for an hour due to a delivery failure that was not the customer’s fault.

Can I have more than one action per rule?

Each rule executes one action. To trigger multiple actions from the same event, create multiple rules with the same trigger and conditions. Since each rule has its own cooldown, they behave independently.

Does the Hold Order action prevent the customer from knowing their order is under review?

WooCommerce sends its standard “order on hold” notification to the customer when an order is moved to on-hold status. This is a standard WooCommerce email that customers may already associate with things like awaiting bank transfer confirmation. If you want to suppress or customize this notification for automation-triggered holds, that requires modifying the WooCommerce email settings independently of TrustLens.

Do automation rules affect the TrustLens free version?

No. Automation Rules are exclusive to TrustLens Pro. The free version surfaces all customer risk data — scores, segments, detection signals — but does not include the rules engine. You can view customer profiles, manually block or allowlist individual customers, and export customer lists in the free version. The Pro upgrade adds the full automation layer. As of plugin version 1.2.3, the full trigger list, condition fields, and action set described in this guide are all Pro-only.