The applicants list is your operational view: every verification your organization has started, with its current status and the applicant's display name.

## The applicants list

Open **Applicants**. The list shows the 50 most recent verifications in your active organization, newest first, scoped to the current mode (`live` or `test`).

Each row shows the applicant's decrypted display name (legal name when filled in, otherwise your operator reference name, otherwise the opaque `app_<id>` chip), the verification id (`vs_<uuid>`) linked to the detail page, a status badge, an outcome badge on `completed` rows, the workflow template name, and the creation timestamp. Names are decrypted server-side under your DEK and never reach the client as a `data-*` attribute or hidden field.

## Status values

A verification moves through a defined set of states:

- `created`: row exists, applicant has not arrived.
- `pending`: the applicant has loaded the start interstitial but not yet consumed the invite link.
- `in_progress`: the applicant is filling out rendered steps.
- `awaiting_gate`: the applicant finished a rendered step that depends on a gated server-side check; the journey is parked in-session so the workflow can route to the next step or a remediation step without an email round-trip.
- `processing`: every rendered step is done; remaining server-only checks are still running. The applicant has been redirected to `/complete` (eager-complete).
- `payment_required`: the execution gate found an insufficient wallet balance (or a frozen wallet) before a paid check ran. No paid check ran, so no cost was incurred. Resumes automatically once funds are added or the wallet is unfrozen.
- `awaiting_review`: the workflow finished and the result requires a human reviewer.
- `completed`: terminal. Carries an outcome (`approved`, `declined`, or `review`).
- `expired`: terminal. Lifecycle expiry.
- `cancelled`: terminal. Operator-initiated.

`completed`, `awaiting_review`, `expired`, and `cancelled` are the four terminal states. `payment_required` is non-terminal.

## Open a verification

Click any row to open the detail page. From there you can read the per-step results and any AI-generated summary, resend or regenerate the applicant invite, export a PDF, make a decision when the verification is `awaiting_review`, and cancel a non-terminal verification.

For the reviewer surfaces, see [Reviewer surfaces](/guides/verification/reviewer-manual-review).

## Filter and search

The filter row narrows the list by status, by an ISO date range on `created_at`, and by workflow template. The form auto-submits 250 ms after any control changes. "Apply filters" is the keyboard-and-no-JS fallback. "Reset" returns to the unfiltered list.

## Find verifications that need action

The two practical "needs attention" filters:

- **`awaiting_review`**: verifications waiting on a human reviewer. Open the detail page and use the decision panel.
- **`payment_required`**: verifications parked on the wallet (insufficient balance or a frozen/locked wallet). If the balance is simply low, add funds or re-subscribe to resume. A **frozen or locked wallet cannot be self-resolved by adding funds**: a dispute freeze clears on its own once the underlying dispute is resolved, and a refund-clawback lock is admin-only, so contact support for an operator wallet-unlock. See [Why does my verification say payment required?](/guides/faq/payment-required).

For a longer-horizon view, see [Insights](/guides/verification/insights).