Track verification status

The applicants list is your operational view of every verification your organization has started, with its current status and the applicant’s display name. It opens on the verifications that wait for a reviewer, and one control widens it to the full history.

The applicants list

Open Applicants. The list opens on the Needs review filter: the verifications that are waiting for a person to make a call. This is the reviewer working set, not the full history, so a verification that is still with the applicant does not appear here.

To see every verification, set the Status filter to All, or click Reset. All is also where in-product links send you when the verification they point at is not in review: the Done button after you create a verification, the Applicants breadcrumb on a verification’s detail page, and the dashboard View all link. The Applicants breadcrumb on the create page is different on purpose. It opens the default Needs review view, because you have not created a verification yet.

In either view, the list shows the 50 most recent matching 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 the given names and family name shown together, with any suffix last, 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.

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” clears every filter and shows all verifications, the same view as the All status option.

Because the list opens on Needs review, “show me everything” is always the All option. There is no empty status value that means the same thing.

When the list is empty

An empty list names which of four situations you are in, and each one carries its next step:

• No applicants yet. Your organization has no verifications at all in this mode. The card offers New applicant.
• You are all caught up. Your organization has verifications, but none are waiting for review. This is the untouched default Needs review view, so you applied no filter and nothing is wrong. The card offers Show all applicants.
• No applicants match these filters. Your organization has verifications, but none in this view. The card offers Show all applicants, which is the cleared All view.
• A bulk import has no rows yet. The list is scoped to one bulk import that is still processing. The notice above the list carries its own Show all applicants link.

Find verifications that need action

Three filters answer “what needs attention?”:

• Needs review (the view the list opens on): verifications waiting on a human reviewer, without the ones the platform parked after an error. This is the reviewer working set, and it is what the Needs review card on the dashboard counts. Open the detail page and use the decision panel.
• Awaiting review: every verification in the awaiting_review status, including the ones an error parked there. It is therefore the same set as Needs review plus those parked verifications, so its count can be higher. A parked verification carries a Verification errored badge in place of Awaiting review, and its detail page names the step that stopped and offers a re-run.
• 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?.

For a longer-horizon view, see Insights.