A verification is one applicant's run through one workflow template. You start the verification, identify the applicant, then hand them a link to start.

## Before you start

You need:

- An active organization (the verification is scoped to whichever organization you have selected).
- At least one [workflow template](/guides/workflows/workflow-templates-create). The new applicant page redirects to workflow template creation if you have none.
- The **Owner** or **Admin** role.

For terminology, see the [Glossary](/glossary).

## Start the verification

Click **New applicant**, or click **+ New applicant** from the Applicants list. The form asks for a workflow template, the applicant's contact details, and (optionally) per-send overrides for the invite email.

The workflow template dropdown lists every active, non-archived workflow template. Check set, branding, and invite copy are inherited from whichever workflow template you pick. The snapshot is frozen at verification creation, so editing the workflow template later does not retroactively change a live verification.

## Identify the applicant

Provide:

- **Full name**: used for the email greeting and for the operator-facing display name on the applicants list. The applicant confirms or corrects their legal name during the journey.
- **Email**: the invite recipient. Encrypted at rest with your data encryption key (DEK).
- **Phone (optional)**: normalized to E.164. National-format numbers without a leading `+` use your browser's `Accept-Language` region as the default country.

Operator-typed values stay on the client until you submit. The stored verification record holds encrypted envelopes; only the applicant's `app_<id>` chip is visible in URLs and logs.

## Expected outcome (test mode)

In **test mode** a verification is free and fully synthetic: it runs no real checks, debits no wallet, and runs no fraud detection. Because no real check produces the result, you choose it yourself with the **Expected outcome** control.

- In the console, the new applicant form shows an **Expected outcome** picker: **Pass**, **Review**, or **Fail** (default **Pass**). It is rendered only in test mode and hidden in live.
- Over the API, set the optional `expected_outcome` field on `POST /v1/sessions` to `pass`, `review`, or `fail`. Omit it to default to `pass`.

The selected outcome drives a coherent synthetic identity-verification result (the document read, face match, and liveness all resolve toward the chosen verdict). This control is **test mode only**: a live-mode create ignores it, so a live verification can never carry a synthetic outcome.

## Choose how the applicant arrives

On success the response panel shows the verification id (`vs_<uuid>`), the applicant URL (the `/v/<code>?o=<otl>` link served by the verify app), and a QR code containing the same URL.

You can either:

1. Let the auto-send invite do its job. The email is composed from the workflow template's `messaging.invite` copy and any per-send overrides, branded with the snapshot's effective branding, and queued in the same transaction that wrote the verification record.
2. Copy the link manually and share it through your own channel.

See [Send a verification invite](/guides/verification/send-an-invite) for resending and editing the invite.

## Track the new verification

The new verification appears at the top of the applicants list with status `created` (or `pending` once the applicant loads the start page). From there it moves through `in_progress` and `awaiting_gate` and ends in `processing`, `payment_required`, `awaiting_review`, `completed`, `expired`, or `cancelled`.

For the full status taxonomy, see [Track verification status](/guides/verification/track-status).

## Next steps

- [Send a verification invite](/guides/verification/send-an-invite)
- [How an invite link works](/guides/verification/one-time-links)
- [Reviewer surfaces](/guides/verification/reviewer-manual-review)
- [Why was a verification declined?](/guides/faq/verification-declined)