# Document Verification Filters

https://docs.wisecp.com/de/document-verification-filters

The rules that decide which clients are asked to verify themselves with documents before they can keep using their account.

## Reaching the Screen

Open **Clients**, then **Document Verification**, then **Filters**: `{admin}/users/document-verification/filters`

The whole Document Verification menu appears only for staff holding the `USERS_DOCUMENT_VERIFICATION` privilege.

## What Is on the Screen

An explanatory bar, a row of controls, and the list of filters. Everything else happens in the dialog that opens when you add or open a filter.

- **Information bar**: A reminder of what filters do: a client caught by one is required to complete verification and cannot use the account until it is done.
- **Controls**: Bulk action, the add button, links to the two sibling pages (**Verification Fields** and **Document Verification Records**), a status filter for the list, and the download button that saves the list as CSV, JSON or XML.
- **Filter list**: One row per filter, with its conditions listed in their own column beside the name.
- **Filter dialog**: Where a filter is actually built: status, name, conditions, and the fields to request.

### The List

- **Name**: Your own name for the filter, for staff only. Clicking it opens the filter for editing.
- **Filters**: The conditions this filter carries, one line each. Only the condition type is listed here, not the value behind it, so open the filter to see the thresholds.
- **Status**: Active or inactive. Only active filters are ever evaluated.
- **Row actions**: Edit and delete, in the menu at the end of the row.

The status control above the list narrows the rows to active or inactive filters, and the choice stays in the address, so a filtered list survives a page reload.

### The Filter Dialog

The same dialog is used to add a filter and to open an existing one. It has four parts, top to bottom:

- **Status**: The switch that puts the filter into service. A new filter opens with it on.
- **Name**: How the filter is labelled in the list and on the client's record on the **Document Verification Records** page. Staff only: the client never sees it.
- **Filters**: The conditions. Each row is one condition: a type on the left, its value on the right, and a bin icon to drop it. The plus button under the rows adds another one, and the last remaining row cannot be removed.
- **Fields**: What the client will be asked for. Pick a field from the list underneath and add it; the chosen fields stack up above and can be dragged into the order the client will see. With no field defined anywhere yet, a warning takes the picker's place and links you to the Verification Fields page.

The save button starts closed and opens as soon as you touch anything in the dialog.

### Condition Types

Eighteen types are available. The numeric ones also carry a comparison (**Equal**, **Less**, **Greater**), which the dialog preselects for you.

| Condition | What it reads | What you enter |
| --- | --- | --- |
| According to Account Type | The account type on the profile. | Individual or Company. |
| According to Age | Age from the date of birth. An account with no date of birth never matches. | An age and a comparison. The **Between** choice has no second value to work with and is evaluated as **Greater**. |
| By Country and City | The country (and optionally the state or city) on the client's address. | A country, and a state or city once the country is chosen. |
| According to Last Login Day | Days since the last sign-in. An account that has never signed in does not match. | A number of days. Matches at that number and above. |
| According to VPN/Proxy Usage | Whether the address the client is connecting from reads as a proxy or VPN. | Yes or No. |
| According to IP Subnet | The address the client is connecting from. | A pattern with `*` for the free parts, such as `192.168.1.*`. |
| According to Reseller Status | Whether the account is a reseller. | Yes or No. |
| According to Affiliate Status | Whether the account has an affiliate record. | Yes or No. |
| According to Client Group | The client group on the account. | One group. |
| According to Total Spending | The sum of the client's paid invoices. Amounts are added up without converting currencies. | An amount and a comparison. |
| According to Order Count | How many orders the account has, of any status. | A count and a comparison. |
| According to Service Count | How many services the account has, of any status. | A count and a comparison. |
| Country Mismatch (IP ≠ Profile) | The country on the profile against the country of the last sign-in. If either one is unknown, the condition does not match. | Yes or No. |
| According to Account Age | Days since registration. | A number of days and a comparison. |
| According to Payment Method | Whether the client has at least one paid invoice settled with that method. | One payment method. |
| According to Email Provider | The domain of the client's e-mail address. | A domain, such as `gmail.com`. |
| According to Failed Payments | Unpaid invoices that are past their due date. There is no separate log of failed attempts, so overdue invoices stand in for payment trouble. | A count and a comparison. |
| According to Product Group | Whether the client owns a service in that group. Domains count as a group of their own. | One product group. |

### How a Filter Catches a Client

A filter's conditions are joined with **or**, not **and**: *one* matching condition is enough to catch the client. Several conditions in one filter therefore widen the net rather than narrowing it. There is no way to require two conditions to hold at the same time, neither inside one filter nor across two. Opening a second filter widens the net again; what it changes is that the second filter's own field list joins the request.

Two things keep a filter out of play entirely: an inactive status, and an empty field list. A filter that asks for nothing has nothing to enforce and is skipped.

When more than one filter catches the same client, their fields are merged into a single request list and duplicates are dropped, so a field two filters both ask for is presented once. Fields whose own status is inactive are left out of that list.

## Fields

- **Name**: Required. Saving with it empty is refused. Staff-facing only: the name appears in this list and on the client's record on the **Document Verification Records** page, in the list row and in the review dialog. The client never sees the filter's name anywhere.
- **Status**: On by default for a new filter. Off keeps the filter and its conditions but takes it out of evaluation.
- **Select a field to add...**: The picker that adds one of the defined verification fields to this filter. At least one field must end up in the list; saving without one is refused. A field already in the list cannot be added twice.
- **Apply to Selected**: Shown only to staff who may edit filters. Delete is its only action, it works on the rows ticked in the list, and it always asks for your own password, even when a single row is ticked.

## Tasks

### Create a filter

1. Use the add button above the list.
2. Name the filter, then set its first condition.
3. Add the fields to be requested and drag them into the order the client should see.
4. Save. The filter joins the list, and with its status on it starts catching clients from the next account check.

### Set the conditions

1. In the **Filters** section of the dialog, choose the type on the left; the fields on the right change with it.
2. Enter the value, and the comparison where the type offers one.
3. Use the plus button for a second condition, remembering that conditions are joined with **or**.
4. Save. The list row now shows every condition type in the **Filters** column next to the filter's name.

### Choose what the client is asked for

1. Pick a field from the picker in the **Fields** section and add it.
2. Repeat for each field, then drag the rows by their handle to set the order.
3. Remove anything you do not need with the cross at the end of its row.
4. Save. The chosen fields are what the caught client sees on their verification page.

### Take a filter out of service

1. Open the filter from its name in the list.
2. Switch **Status** off and save.
3. The row now reads **Inactive**. No new client is caught by it, and the clients it already caught are released from its request, unless another active filter asks for the same fields.

### Delete filters

1. For one filter, use delete in its row menu.
2. For several, tick their rows and choose **Delete** under **Apply to Selected**. That route always asks for your own password, so use the row menu when a single filter is going.
3. Confirm. The rows leave the list, and the documents clients already submitted stay where they are, because those belong to the fields rather than to the filter.

## Things to Watch

> **A caught client stays caught**
> 
> The moment a client trips a filter, the match is written onto their account. Editing the conditions afterwards does not release them: while the filter stays active its rules are never weighed again. Switching the filter off or deleting it does drop its request. Test a new filter on a narrow condition before widening it.

> **An active filter locks accounts, not just flags them**
> 
> A caught client cannot use their panel until every requested field carries a verified record. Turning a broad filter on therefore stops existing clients in their tracks, and the queue it creates is worked through on the Document Verification Records page.

> **An inactive field is silently skipped**
> 
> The picker offers every defined field, inactive ones included, but it does not mark them there: the **Inactive** badge appears only once the field has been added to the list above. An inactive field sits in the filter without ever being asked, so a filter holding only inactive fields catches clients and requests nothing from them.

## Required Privileges

The whole screen sits behind `USERS_DOCUMENT_VERIFICATION`: without it the menu entry is not drawn and the page refuses to open. The same privilege covers every action here (adding, editing, deleting and bulk deleting filters), so there is no read-only level for this screen. Downloading the list additionally requires `TABLE_EXPORT`; without it the download button is not drawn.

## Related Articles

- [Verification Fields](https://docs.wisecp.com/en/verification-fields)
- [Document Verification Records](https://docs.wisecp.com/en/document-verification-records)
- [Client List](https://docs.wisecp.com/en/client-list)