Automation Overview

The Automation Rules engine is the Pro feature that lets TrustLens act on what it detects. Rules are trigger-condition-action sequences — “when X happens, if Y is true, then do Z” — that fire when customer risk changes, orders are placed, refunds happen, disputes are filed, linked accounts are detected, card-testing attacks happen, or shipping anomalies are spotted. Without the engine, TrustLens surfaces risk for human moderation; with it, you can build closed-loop workflows that act in seconds without admin attention.

Location: TrustLens → Automation.

---

The Rule Shape #

Every rule has three sections:

Section	What It Does
Trigger	The event that wakes the rule up. One trigger per rule. Examples: “Order placed,” “Chargeback filed,” “Score updated.”
Conditions	Filters that must all be true for the rule to act. Multiple conditions combine with AND. Examples: “trust_score < 30,” “total_disputes >= 2.”
Actions	What the rule does when it fires. Multiple actions can be listed; they run in order. Examples: “Block customer,” “Send email,” “Fire webhook.”

Rules can be enabled or disabled independently. Disabled rules don’t fire even when their trigger conditions occur.

---

What’s Available #

Component	Count	Details
Triggers	15	See Triggers Reference
Condition fields	22	See Conditions Reference
Actions	10	See Actions Reference

---

Example Rule #

“When a chargeback is filed against a customer who has 2+ existing disputes and trust score under 30, block the customer and fire a webhook to your alerting channel.”

• Trigger: Chargeback Filed
• Conditions: total_disputes >= 2 AND trust_score < 30
• Actions: Block customer; Fire webhook to a Slack incoming webhook URL for #fraud-alerts

This is a typical “tighten the noose” rule — escalate enforcement automatically when a known-risky customer crosses a new threshold.

---

How Rules Run #

When a trigger event fires, the automation engine:

1. Collects all enabled rules with that trigger
2. For each rule, evaluates the conditions against the event context
3. If all conditions pass, queues the rule’s actions for async execution
4. Each action runs through the dispatcher with automatic retry on failure (60s / 120s / 240s backoff)
5. Results are logged for inspection

The engine is async — rule actions don’t block the triggering event. A new order or refund proceeds normally even if rule actions are still being dispatched.

---

The Save-Time Validator #

When you save a rule, TrustLens validates it before accepting:

• Schema validation — trigger, conditions, actions all match expected types
• Unsatisfiability check — can the conditions possibly be true together? A rule with trust_score > 80 AND trust_score < 20 is rejected as unsatisfiable
• Contradiction check — actions and conditions don’t contradict (e.g. a rule conditioned on “is_blocked = true” with an action “Block customer” is flagged)
• Trigger-condition compatibility — the conditions can be evaluated in the trigger’s context

Invalid rules are rejected at save time with a specific error message. This prevents the most common failure mode of automation engines: silently-broken rules that never fire.

---

The Rule Inspector #

For each saved rule, the Automation page shows recent firing activity:

• Last 10 evaluation results
• For each: timestamp, trigger event, conditions met / not met, actions dispatched
• SKIP reasons when the rule didn’t fire: “Cooldown active,” “Condition not met: trust_score > 50”

This is the answer to the perennial question “why didn’t my rule fire?” — you can see exactly which condition rejected the event.

---

Cooldowns #

Each rule can have a cooldown period — minimum time between firings on the same target. Useful for:

• Preventing alert spam when a customer triggers a rule repeatedly
• Rate-limiting expensive actions (emails, webhook calls)
• Ensuring you don’t double-block a customer who briefly recovered and then re-triggered

Default cooldown is none. Configure per-rule.

---

Logging #

Every rule evaluation and action dispatch is logged:

• Rule ID, trigger event, condition results
• Each action: dispatch attempt, response, success/failure
• Retry attempts with backoff timing
• Final outcome (success / failed after retries / skipped)

The Automation Log is searchable by rule, by customer, by date range. Retention is 90 days by default (configurable).

---

Common Rule Patterns #

• Escalation: Risk → Critical triggers alert + hold orders
• Block-on-dispute: Chargeback filed + customer score < 30 → block
• VIP fast-track: Order placed + segment = VIP → tag order for priority fulfillment
• Linked-account warning: Linked accounts detected + linked_accounts ≥ 3 → fire webhook (point it at Slack)
• Coupon abuse mitigation: Order placed + coupon_then_refund ≥ 2 → cancel order
• Card-testing follow-up: Card testing attack detected → email summary report to ops lead
• High-value monitoring: Order placed + order_total > $1000 + segment ≠ VIP → flag for review

---

Engine Performance #

Rule evaluation is fast — typically < 5ms per rule per event. Most triggers evaluate dozens of rules without measurable impact on the triggering event’s latency. Actions are async, so even slow actions (webhooks to slow external services) don’t slow down the event flow.

Stores running 50+ automation rules see no notable performance impact. The engine scales beyond that, but at some point you should think about whether your rule set has consolidation opportunities.

---

Disabling Automation #

To disable the entire engine: Settings → Automation → Disable engine. While disabled:

• No triggers are evaluated
• No actions fire
• Existing rules remain saved
• Re-enabling resumes from the next trigger event

Disabling is useful during major operational changes (migrations, new gateway integrations) where rule actions might produce noise.