---
title: Conditions Reference
description: "Conditions are the filters that determine whether a rule's action fires. Each condition is a comparison against a field — a customer attribute, an order property, or (on Refund Processed) a property of the refund. Conditions combine with AND logic;…"
url: "https://webstepper.io/docs/trustlens/automation/conditions-reference/"
updated: "2026-10-18"
category: Automation
---

# Conditions Reference

Conditions are the filters that determine whether a rule's action fires. Each condition is a comparison against a field — a customer attribute, an order property, or (on Refund Processed) a property of the refund. Conditions combine with AND logic; all must be true for the rule to act. This page lists all 46 condition fields in the rule editor (25 customer fields, 6 order-only fields and 15 refund-only fields), the comparison operators they support, and example expressions.

The 6 order-only fields can only be used with an order-bearing trigger (`order_placed`, `order_completed`, `refund_processed`, or `dispute_recorded`), because those are the only triggers that carry an order context. The 15 refund fields can only be used with `refund_processed`.

---

## Anatomy of a Condition

A condition has three parts:

1. **Field** — what to compare. E.g. `trust_score`, `order_total`, `segment`
2. **Operator** — how to compare. One of `<`, `<=`, `=`, `!=`, `>=`, `>`
3. **Value** — what to compare against, typed into a text box. E.g. `30`, `vip`, `US`

Example: `trust_score < 30` — true when the customer's score is below 30.

Conditions are optional. A rule with no conditions fires on every event from its trigger.

---

## Customer Fields

These 25 fields are available with every trigger. They are read from the customer's TrustLens record; when the customer has no record yet (for example a first card-testing attempt from a never-seen email), customer conditions don't match and the rule is skipped.

| Field | Type | Operators |
| --- | --- | --- |
| `trust_score` | integer 0–100 | <, <=, =, !=, >=, > |
| `segment` | enum (vip / trusted / normal / caution / risk / critical) — lowercase, matched exactly | =, != |
| `return_rate` | decimal 0–100 (percent) | <, <=, =, !=, >=, > |
| `customer_type` | enum (user / guest) — registered account or guest checkout | =, != |
| `total_orders` | integer — counted orders (completed, or refunded) | <, <=, =, !=, >=, > |
| `total_order_value` | decimal — the customer's lifetime spend across counted orders (not the current order; use `order_total` for that) | <, <=, =, !=, >=, > |
| `cancelled_orders` | integer | <, <=, =, !=, >=, > |
| `total_refunds` | integer — refunded orders | <, <=, =, !=, >=, > |
| `total_refund_value` | decimal | <, <=, =, !=, >=, > |
| `full_refunds` | integer | <, <=, =, !=, >=, > |
| `partial_refunds` | integer | <, <=, =, !=, >=, > |
| `total_coupons_used` | integer | <, <=, =, !=, >=, > |
| `first_order_coupons` | integer | <, <=, =, !=, >=, > |
| `coupon_then_refund` | integer | <, <=, =, !=, >=, > |
| `total_disputes` | integer | <, <=, =, !=, >=, > |
| `disputes_won` | integer | <, <=, =, !=, >=, > |
| `disputes_lost` | integer | <, <=, =, !=, >=, > |
| `linked_accounts` | integer — number of accounts linked to this customer. Works from 1.3.23; earlier versions always read 0, so rules on it never matched | <, <=, =, !=, >=, > |
| `order_edits` | integer — no module records order edits yet, so this is currently always 0 | <, <=, =, !=, >=, > |
| `is_first_order` | boolean — on Order Placed, true when the customer has no counted orders yet (the order being placed isn't counted until it completes); on other triggers, true when `total_orders` equals exactly 1 | =, != |
| `is_blocked` | boolean | =, != |
| `is_allowlisted` | boolean | =, != |
| `is_flagged` | boolean — flagged for review | =, != |
| `customer_age_days` | integer — days since the first order date (no match when there's no first order date) | <, <=, =, !=, >=, > |
| `days_since_last_order` | integer — days since the last counted order (no match when there's none) | <, <=, =, !=, >=, > |

---

## Order Fields

These 6 order-only fields require an order-bearing trigger (`order_placed`, `order_completed`, `refund_processed`, or `dispute_recorded`). They aren't available with customer- or detection-level triggers, which carry no order context.

| Field | Type | Operators |
| --- | --- | --- |
| `order_total` | decimal — the total of *this* order | <, <=, =, !=, >=, > |
| `coupon_total` | decimal — the discount on this order | <, <=, =, !=, >=, > |
| `payment_method` | string — the gateway ID (e.g. `stripe`, `cod`, `bacs`), matched exactly | =, != |
| `shipping_country` | string (ISO-2), case-insensitive | =, != |
| `billing_country` | string (ISO-2), case-insensitive | =, != |
| `country_mismatch` | boolean — true when the order has a shipping country that differs from the billing country (no shipping country counts as no mismatch) | =, != |

---

## Refund Fields

These 15 fields describe the refund that fired a **Refund Processed** rule and can't be used with any other trigger.

| Field | Type | Operators |
| --- | --- | --- |
| `refund_amount` | decimal — this refund | <, <=, =, !=, >=, > |
| `refund_ratio` | decimal — percent of the order refunded so far, including this refund | <, <=, =, !=, >=, > |
| `cumulative_refunded_amount` | decimal — total refunded on the order so far | <, <=, =, !=, >=, > |
| `refund_type` | enum (full / partial) | =, != |
| `refund_classification` | string (e.g. `customer_return`, `duplicate_payment`, `pre_fulfillment_cancellation`, `unknown`) | =, != |
| `refund_reason` | string — the reason typed on the refund, matched exactly | =, != |
| `refund_currency` | string — uppercase currency code (e.g. `USD`) | =, != |
| `refund_transition` | string — e.g. `none_to_partial`, `partial_to_full`, `none_to_full` | =, != |
| `days_since_order` | integer | <, <=, =, !=, >=, > |
| `refund_item_count` | integer — refunded line items | <, <=, =, !=, >=, > |
| `refund_itemized` | boolean — the refund includes line items | =, != |
| `fulfillment_status` | string — the order status (e.g. `completed`, `processing`) | =, != |
| `order_delivered` | boolean — the order has delivery evidence | =, != |
| `processed_by_user_id` | integer — WordPress user who issued the refund (0 when unknown) | <, <=, =, !=, >=, > |
| `processed_by_role` | string — matches when the refunding user has that role (e.g. `shop_manager`) | =, != |

---

## Operators in Detail

### Comparison Operators

`<`, `<=`, `=`, `!=`, `>=`, `>` — the full operator set shown in the editor. `==` is accepted as an alias for `=`, and `<>` as an alias for `!=`. The ordering operators (`<`, `<=`, `>=`, `>`) only work on numeric fields; the validator rejects them on text, enum and yes/no fields.

### Enum and String Fields

Enum and string fields (such as `segment`, `customer_type`, `payment_method`, and the country fields) use `=` and `!=`. Values are matched exactly — `segment = VIP` never matches because segments are stored lowercase; write `segment = vip`. Only the two country fields ignore case. To match several values, create one rule per value with the same action.

### Boolean

Use `=` or `!=`. The values `1`, `true` and `yes` mean true; anything else (including `0` and `false`) means false. Example: `is_blocked = 0`.

---

## Multi-Condition Logic

Conditions combine with AND only — all must be true for the rule to act. There's no OR or grouped boolean logic at the rule level.

To express OR logic, create multiple rules with the same action. Example: "block if score < 30 OR if disputes ≥ 2" becomes two rules, each with one condition, both with the Block Customer action.

---

## Example Condition Sets

| Intent | Conditions |
| --- | --- |
| "Critical customer placing high-value order" | `segment = critical` AND `order_total > 500` |
| "Risk customer shipping to a different country than they bill to" | `segment = risk` AND `country_mismatch = 1` |
| "Customer at dispute threshold" | `total_disputes >= 2` |
| "First order with a large discount" (Order Placed) | `is_first_order = 1` AND `coupon_total > 50` |
| "Customer linked to several other accounts" | `linked_accounts >= 3` |
| "VIP placing a large order" | `segment = vip` AND `order_total > 1000` |
| "Full refund on an order with no delivery evidence" (Refund Processed) | `refund_type = full` AND `order_delivered = 0` |

---

## The Save-Time Validator and Conditions

When you save a rule with conditions, the validator checks:

- Each field is a known field and is allowed with the rule's trigger (order fields need an order trigger, refund fields need Refund Processed)
- Each operator is valid for the field's type, and each value is possible for the field (e.g. a trust score between 0 and 100)
- The combined conditions are satisfiable (no contradictions like `trust_score > 80 AND trust_score < 20`, or `total_orders = 0` with `total_order_value > 0`)
- No condition contradicts what the trigger guarantees (e.g. `is_allowlisted = 0` on a Customer Allowlisted rule)

Conditions are optional — a rule with none is valid and fires on every trigger event. Blank condition rows are ignored. Invalid rules fail to save with a specific error message.

---

## Performance

Conditions evaluate against in-memory data — the customer record (fetched once per trigger event) plus the order or refund in scope. Each condition is sub-millisecond. Even rules with 10+ conditions evaluate in under 10ms.

The engine is bound by trigger volume, not condition complexity.