--- title: Blocking and Allowlisting description: "Blocking and allowlisting are TrustLens's two primary moderation actions. Blocking prevents a customer from completing checkout; allowlisting locks a customer at score 100 and suppresses all negative signals. They're opposite tools for opposite situations — one for customers you don't…" url: "https://webstepper.io/docs/trustlens/customer-management/blocking-and-allowlisting/" updated: "2026-10-18" category: Customer Management --- # Blocking and Allowlisting Blocking and allowlisting are TrustLens's two primary moderation actions. Blocking prevents a customer from completing checkout; allowlisting locks a customer at score 100 and suppresses all negative signals. They're opposite tools for opposite situations — one for customers you don't want to transact with, one for customers you never want flagged. This page covers when to use each, exactly what each does, and how they interact with the rest of the system. --- ## Blocking Blocking is the action you take on a customer whose behavior makes you decide not to transact with them anymore. ### What It Does - Sets `is_blocked = true` on the customer's record - If the **Enable Blocking** setting is on, the customer cannot complete checkout - Classic checkout, Blocks checkout and the pay-for-order page are all enforced. A logged-in blocked customer is also stopped by classic (non-block) add-to-cart buttons, because their account email is known - The customer sees a generic error message (customizable in settings) - The block and its reason are logged in the customer's event timeline - The customer's score is not changed by blocking — it remains whatever the signals produced Two kinds of customer are never stopped at checkout, even when blocked: **allowlisted** customers, and anyone logged in as a store admin or shop manager (users who can manage WooCommerce). Test blocks while logged out. ### What It Doesn't Do - Doesn't prevent the customer from browsing your store - Doesn't notify the customer that they've been blocked - Doesn't cancel existing orders or refunds - Doesn't prevent the customer from logging in to their WordPress account if they have one - Doesn't add them to a server-level firewall ### Recording a Block Reason When you block a customer, TrustLens asks *why*. A prompt offers a set of preset reasons plus an optional free-text detail field: - High return / refund abuse - Coupon abuse - Linked to fraud ring - Card testing / chargebacks - Manual review — suspicious activity - Other Whatever you pick (and anything you type in the details field) is saved to the customer's notes and event log, so you keep an audit trail of why each customer was blocked. This is optional context, not a gate — but recording it makes later review, appeals, and dispute evidence far easier. ### Actions Happen In Place Blocking and unblocking update right where you're working — no full page reload. A confirmation toast appears in the corner. Allowlist and recalculate also confirm with a toast and keep your scroll position, so you never lose your place. ### The Master Toggle Blocking only enforces at checkout if the **Enable Blocking** setting ("Allow blocking customers from checkout") is on. This master toggle defaults to **off** so you can mark customers as blocked, observe scoring, and choose your moment to actually enforce. To enable enforcement: **TrustLens → Settings → General → Blocking Settings → Enable Blocking**. ### The Block Message Customers attempting checkout while blocked see a generic, neutral message — by default: "We are unable to process your order at this time. Please contact support for assistance." The wording is intentionally non-specific. It doesn't tell the customer they've been blocked, what triggered it, or how to appeal. This is deliberate — revealing the block surface invites adversarial probing and gives bad actors information they can use. You can customize the message in **Settings → General → Block Message**. Keep it neutral. ### When to Block - Critical-segment customers with confirmed multi-module abuse - Customers with 2+ lost disputes - Confirmed fraud-ring members (linked-account analysis confirms shared identity) - Customers with explicit policy violations (terms-of-service breach) - Pro: automated blocks via the automation engine ### When Not to Block - Caution-segment customers — too early, observation is the right move - Risk-segment customers with one signal — investigate first - VIPs or long-tenured customers — even with negative signals, manual review is required - Customers in active dispute resolution — let the process play out --- ## Allowlisting Allowlisting is the action you take on a customer you never want flagged by TrustLens. ### What It Does - Sets `is_allowlisted = true` on the customer's record - Clears any block and any review flag - Locks the trust score at 100 - Locks the segment at VIP - Short-circuits scoring entirely — no signals are computed - Skips the blocked-customer check at checkout - Bypasses Card-Testing Defense velocity rules when VIP Customer Bypass is on (the default) and the customer also has at least the Full-confidence Order Threshold of orders (default 3) - The allowlisting is logged in the event timeline ### What It Doesn't Do - Doesn't grant the customer any special privileges in WooCommerce - Doesn't notify the customer ### Allowlisting Locks the Score at 100 The allowlist is implemented as a short-circuit in the scoring engine. The first check the engine does is "is this customer allowlisted?" If yes, return score = 100, segment = VIP, and stop. No module signals are computed for allowlisted customers. This means allowlisting is durable — future bad behavior won't lower the score until you remove the allowlist. It's the right tool for customers who matter enough that you want them protected from any signal, including ones you haven't anticipated. ### When to Allowlist - Top customers by lifetime value - Strategic accounts (B2B, key partnerships) - Customers you've personally vetted and want immune to false positives - Family members, employees, friends shopping at your store - QA test accounts you don't want polluting your scoring metrics ### When Not to Allowlist - Customers who are merely "good so far" — let them earn VIP organically - Customers you don't personally know — allowlist is a trust signal, use it accordingly - Broad cohorts — allowlist is per-customer, not per-segment --- ## Block + Allowlist Interaction Allowlisting clears the block, so the two flags normally don't overlap. A customer can only end up with both if they're blocked *after* being allowlisted: | Block | Allowlist | Effect | | --- | --- | --- | | No | No | Normal — score computed from signals, normal checkout | | Yes | No | Score from signals; checkout blocked if Enable Blocking is on | | No | Yes | Score locked at 100, segment VIP; normal checkout | | Yes | Yes | Score locked at 100, and checkout is *not* blocked — allowlisted customers skip checkout enforcement. To stop this customer, remove them from the allowlist. | The fourth case is rare. If you find yourself in it, decide which one you meant — usually one or the other is correct. --- ## Per-Customer vs Global Both blocking and allowlisting are per-customer actions. There's no segment-wide "block all Critical" or "allowlist all VIP" toggle in Free. Pro adds automation rules that can effectively produce this behavior on incoming events ("if segment changes to Critical, set blocked"), but the state is still tracked per-customer. --- ## Bulk Operations The Customers list supports bulk block / unblock / allowlist / remove-from-allowlist actions. Select rows with the checkbox column, choose an action from the bulk-action dropdown, and click Apply. See [Bulk Actions](/docs/trustlens/customer-management/bulk-customer-actions/). --- ## Undoing Actions Both actions are reversible. Unblock restores normal checkout; remove-from-allowlist restores normal scoring. The event timeline preserves the historical state — you can see when the customer was blocked and unblocked. Removing a customer from the allowlist queues a score recalculation, which runs shortly afterwards — the score drops back to whatever the underlying signals produce. A block that was cleared when they were allowlisted isn't restored. --- ## Customer-Facing UX Neither action produces customer-facing notifications. Customers don't see when they're blocked or allowlisted. The only customer-facing manifestation is the checkout error message during a block. If you need to communicate with a blocked customer (e.g. for appeals), do so out-of-band — direct email, phone. Don't try to communicate via the checkout error message. --- ## The Admin Audit Trail Every block, unblock, allowlist, and remove-from-allowlist action is logged as an event with: - Timestamp - Customer affected - The action (`customer_blocked`, `customer_unblocked`, `customer_allowlisted`, `customer_allowlist_removed`) - The reason, for blocks (also saved to the customer's admin notes) Events don't record which admin performed the action. The trail is visible per customer, in Recent activity on the customer's profile, and through the REST API's events endpoint; there's no global audit page.