Automation Rule Not Firing

You built an automation rule that should be firing, but the action isn’t happening. This page is the diagnostic walkthrough for figuring out why. The Pro automation engine includes a Rule Inspector that surfaces SKIP reasons for every evaluation — most of the time, the answer is right there.

---

Step 1: Use the Rule Inspector #

The Rule Inspector is the first stop. It shows recent runs of the rule with specific reasons for outcomes.

1. Go to TrustLens → Automation
2. Click the rule in the list
3. Look at the Recent runs panel (latest 10 attempts)

You’ll see entries like:

Badge	Reason
OK	(all conditions passed; the action ran)
SKIP	“Condition not met: trust_score < 30”
SKIP	“Cooldown active”
SKIP	“Guest order: no customer email hash”
QUEUED	(webhook waiting for delivery, or a hold waiting for the order’s payment)
ERR	“Webhook returned HTTP 500 after 4 attempt(s).”

The reason line tells you exactly why the rule didn’t act. Most diagnostic work ends here.

---

Step 2: No Activity at All #

If Recent runs says “This rule has not fired yet,” the rule isn’t being evaluated. Possible causes:

Engine Paused #

Check the page header on TrustLens → Automation: it reads “Engine running” or “Engine paused.” The engine is off by default — turn on the Engine running switch and click Save. While paused, no rules fire and nothing is logged. Rules also stop firing if the Pro license lapses.

Rule Disabled #

Check the rule’s Rule is active switch in the editor (disabled rules are marked as off in the list). Disabled rules aren’t evaluated, so they leave no log rows.

Trigger Event Hasn’t Happened #

The rule is configured correctly but the trigger event (e.g. “Chargeback Filed”) hasn’t fired since the rule was created. There’s no “Test Rule” button — trigger the event yourself to test: place a test order for Order Placed, click Recalculate on a test customer’s profile for Score Updated, or block and unblock a test customer for the status triggers.

Wrong Trigger #

Verify the rule’s trigger matches the event you expect:

• Segment Changed fires only when a customer moves into a different segment; Score Updated fires on every recalculation.
• Order Placed fires once per order placed through the classic or block checkout. Orders created in the admin, through the REST API or as subscription renewals never fire it.
• Card Testing Attack and Challenge Failed only reach rules when the attempt carried a billing email.
• Linked Accounts Detected runs after an order is placed (or during Historical Sync), not when you open a profile.

---

Step 3: “Condition not met” #

The most common SKIP reason. The inspector shows the condition that failed, as you wrote it:

Condition not met: trust_score < 30

This tells you:

• You configured a condition expecting trust_score < 30
• The customer’s actual trust score wasn’t below 30 (open their profile to see the value)
• Therefore the rule didn’t fire

Options:

• Adjust the condition — if your intent was to catch this customer, the condition is too strict
• Wait for the customer to actually meet the condition — if your intent was to act only on score < 30, the rule is working correctly; this customer just doesn’t qualify yet
• Use a different condition — maybe segment is what you really want to filter on, not raw score

Common reasons a condition you expected to pass fails:

• Wrong case. Segment values are lowercase and matched exactly — segment = VIP never matches; use vip. The same goes for payment_method (use the gateway ID, e.g. stripe). Only the country fields ignore case.
• Booleans. Only 1, true or yes mean true.
• Wrong total. order_total is this order; total_order_value is the customer’s lifetime spend.
• Linked Accounts before 1.3.23. The linked_accounts condition always read 0 on earlier versions, so a rule like linked_accounts >= 2 never matched. Update to 1.3.23; counts refresh as customers place orders (or re-run Historical Sync).
• No customer record yet. Customer conditions fail when the customer has no TrustLens record — common for a first card-testing attempt from a never-seen email.
• Order Edits. order_edits isn’t populated by any module yet and is always 0.

Conditions are AND-only, and the inspector reports only the first one that failed.

---

Step 4: Cooldown Active #

Customer-level actions have a fixed cooldown: a rule runs at most once per hour for the same customer:

Cooldown active

The rule will fire again for that customer after the hour has passed. This is intentional — cooldowns prevent spam and stop rules from re-triggering themselves. There’s no cooldown field in the rule editor; developers can shorten it (or set it to 0 on a staging site while testing) with the trustlens/automation/rule_cooldown filter. Order actions (Hold Order, Cancel Order, Require Verification, and Flag for Review on an order trigger) have no cooldown.

---

Step 5: ERR Rows #

If conditions passed but the action failed, the inspector shows an ERR row with the reason.

Common action failures:

Action	Common Failure	Fix
Send Webhook	Non-2xx response (including a redirect), timeout, DNS failure — logged after the last retry	Verify receiver URL (use the final URL), test manually. A Slack incoming-webhook URL always fails — route through Zapier, Make or your own endpoint
Send Webhook	“Invalid webhook URL.”	Fix the URL in the action value
Hold / Cancel order, Require Verification	“Action requires an order trigger (Order Placed, Order Completed, Refund Processed, or Dispute Recorded).”	The event had no order — e.g. a Dispute Recorded whose order couldn’t be loaded

Some failures don’t produce an ERR: Send Email doesn’t report mail delivery problems, and Send Email, Add Admin Note and Add Tag quietly do nothing for a customer with no TrustLens record.

---

Step 6: Order Not Held (Order Placed Rules) #

From 1.3.23, Hold Order, Cancel Order and Require Verification on Order Placed don’t change the order at checkout. The order is still waiting for payment at that point, so TrustLens:

1. Stores the action on the order (meta _trustlens_deferred_hold), adds the note “TrustLens: automation rule “…” will hold this order once the payment is confirmed,” and logs the run as QUEUED
2. Applies it when the payment is confirmed — the order goes to on-hold instead of processing (no “processing” email), or is moved to on-hold if it reaches processing or completed another way
3. Logs a second, OK row

So if an order isn’t on hold yet:

• QUEUED with no OK row — the order hasn’t been paid. It stays pending (or failed) until the customer pays; an abandoned order is never held.
• Deferred Cancel Order on a paid order — it’s held instead, with a note asking you to refund if you cancel it. TrustLens never cancels an order whose payment was taken. An unpaid order (e.g. bank transfer awaiting payment) is cancelled.
• No QUEUED row at all — the rule didn’t match; go back to Step 3.

On versions before 1.3.23 these actions changed the status during checkout, before payment. On the block checkout that could let the order through as processing without the payment being taken; on the classic checkout the gateway moved the held order back to processing. If orders “weren’t held” or arrived unpaid on an older version, update to 1.3.23 and check those orders’ payments.

---

Step 7: Check the Save-Time Validator #

Some rules are rejected at save time. If your rule won’t save, the validator caught:

• Unsatisfiable conditions (impossible combination like score > 80 AND score < 20)
• An operator that doesn’t fit the field (e.g. > on segment) or a value outside the field’s range
• Trigger incompatibility (an order field or order action on a non-order trigger, a refund field on anything but Refund Processed)
• A missing action value (Send Webhook URL, tag name) or an invalid email address for Send Email

The error message tells you what’s wrong. Fix and try saving again.

---

Step 8: Verify Field Availability #

Some condition fields only have a value with specific triggers:

• Order fields (order_total, payment_method, the country fields…) need an order trigger
• Refund fields (refund_amount, refund_type…) need Refund Processed
• Customer fields need the customer to have a TrustLens record

The save-time validator rejects order and refund fields on the wrong trigger. A missing customer record only shows up at run time, as a “Condition not met” SKIP.

---

Step 9: Check Action Scheduler #

Most rule actions run synchronously the moment a rule matches. The one exception is the Send Webhook action: outgoing webhook delivery (and its retries) is queued through Action Scheduler, so a stalled queue can leave webhooks QUEUED but never actually sent.

1. Open WooCommerce → Status → Scheduled Actions
2. Filter by hook trustlens/automation/dispatch_webhook
3. Look for pending actions that never complete

If the queue is stalled, see Scores Not Updating Step 3 for cron fixes. Holds waiting for payment don’t use Action Scheduler — they’re applied when the order’s status changes.

---

Step 10: Common Patterns of “Fired But No Effect” #

• Block customer: Block flag set but Enable Blocking is off, or the customer is allowlisted. See Checkout Blocking Not Working.
• Send email: Email sent but deliverability issue. Check spam, check WordPress mail logs.
• Send webhook: Webhook returned 2xx but receiver did nothing. Receiver-side bug.
• Hold order: QUEUED and waiting for payment (Step 6), or the order is on-hold but you didn’t notice in WooCommerce’s order list.
• Flag for review on an order trigger: the order is flagged (a “Flagged” mark in the orders list), not the customer — so the customer won’t appear under the Flagged filter.

---

Step 11: Read the Full Automation Log #

For runs older than the Rule Inspector’s 10-entry window, there’s no log screen — query the {prefix}trustlens_automation_logs table directly:

SELECT created_at, status, action_type, order_id, error_message
FROM wp_trustlens_automation_logs
WHERE rule_id = '…'
ORDER BY created_at DESC
LIMIT 100;

Rows are kept for 90 days. Useful for “this rule worked last week but stopped” investigations — you can compare healthy historical entries with current failures. The inspector’s Last 7 days panel and 14-day sparkline also show when the rule stopped firing.

---

Common Mistakes #

• Conditions too strict — most “rule not firing” issues are simply customers not meeting all conditions
• Uppercase values — segment = Critical instead of critical
• Wrong trigger — picking a trigger that fires too rarely, or Order Placed for orders created in the admin
• Cooldown forgotten — retesting the same rule on the same customer within the hour
• Disabled toggle — accidentally disabled rule, or the engine left paused
• Webhook URL problems — a typo, a redirecting URL, or a Slack URL used directly