Every verification attempt is recorded and can be reviewed in the Verification Checks record.
What the statuses mean
- Pending — created, not yet sent to the provider.
- Awaiting user — the user is mid-flow, or has been sent a link. Waiting on them.
- In review — the provider, or an administrator, is still deciding. Waiting on you or them.
- Verified — passed. May carry an expiry date.
- Rejected — failed.
- Expired — passed once, but validity has run out.
- Cancelled — abandoned by the user or an administrator.
- Error — the provider call failed; the reason is recorded on the check.
A user who has never attempted a type has no check at all, which is different from having been rejected — one is an invitation, the other a refusal, and your interface should say so.
The event trail
The Verification Events record holds every step of every check: when it was created, when it went to the provider, when a result arrived, and every status change with its source. This is what you read when a customer insists they passed and the record disagrees.
Users cannot see or affect each other's checks
A user can only ever start, view or abandon their own verification, and nothing a user submits can declare them verified. Results are accepted only from the provider through a verified channel.
Duplicate attempts
Starting a check when one is already in progress resumes the existing one rather than opening a second, so a customer clicking twice does not create a mess.
Worked Examples
- "I verified last week and it's not applied" — check the status; expired and rejected look very different to the customer.
- Support queue triage: filter for error status to catch provider-side problems before customers report them.