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.