Finding a verification

When a customer tells you they could not sign in, you need their attempt — not the list.

Filtering

The filters that answer most questions:

Filter	Use it when
User	You know who to look for. This matches the identifier you sent as user_id
Date range	Narrow to when they say it happened
Decision	Show only failures, or only referrals
Action	Isolate one step — liveness, face verification, voice verification
Services	Find every attempt that ran a particular check
Tags	Retrieve a set you marked earlier

Filtering by user and date is usually enough. Add decision when you want the failures without the successful retries around them.

The user column shows what you sent

The platform stores one identifier per person — the value you supplied. If you send opaque IDs, that is what appears. Console sign-ins resolve to the account’s email; anything else shows as you sent it, shortened, with the full value available to copy.

Overriding a decision

A reviewer can replace a transaction’s decision — confirming a genuine user the system referred, or rejecting one it passed.

The override does not erase the original. Both are kept, with who changed it and when, so the record still shows what the platform decided on its own. That history is what makes overrides safe to use: you can always separate what the system concluded from what a person concluded afterwards.

Use it for genuine review outcomes. It is a record of a human judgement, not a way to tidy up results.