Checking a Status

Every check is recorded with its outcome, its history and its expiry, so "is this person verified?" is answerable directly.

Where to find it

Architect Panel → Security:

• User Verification — the console — providers, types, checks and their history

Architect Panel → Activity:

• Activity Log — the group award that followed a success

What a check records

• The type and provider.
• The user, by three-part identity, and the e-mail used.
• The status.
• The provider reference — needed if you ever have to ask them about it.
• The outcome and a short evidence summary.
• A failure reason where it did not succeed.
• Requested, completed and expires timestamps.
• The address and browser it came from.
• Where it originated — a form stage, a request, a journey step.

Read the events, not just the status

Each check carries a history of transitions — what it moved from and to, what caused it, when, and from where. A check sitting at an unexpected status is explained by its events far more often than by its current state.

This is where you see that a user started a check and never completed it, or that a provider callback arrived twice.

Check the expiry, not just the outcome

A successful check that has since expired is not current verification. The commonest confusion here is reading a success and not noticing its date — particularly for affiliation, which typically lasts a year.

The source field answers "why was this asked for?"

When a user says they were unexpectedly asked to verify, the source tells you which form, request or process triggered it. That turns a vague complaint into a specific configuration question.

Failure reasons before contacting support

Most "verification is broken" reports are explained by the recorded failure reason — a document that could not be read, a mismatch, an expired link. Read it first; it is usually enough to advise the user without involving the provider.

Keep the provider reference

If you do need to raise something with the provider, that reference is what lets them find the transaction. Quote it rather than describing the user.

Do not re-run a check to diagnose it

It costs money, it asks the user to submit a document again, and it usually produces the same result. Read the existing record first.

Worked example

A user says they verified but cannot reach the content it was supposed to unlock. The check shows a success — completed fourteen months ago, against a type with 365-day validity. It expired a fortnight earlier. They are asked to re-verify, which takes a minute, and the whole enquiry is answered from one screen.

Recommendations

• Read the expiry with the outcome.
• Use the event history for anything unexpected.
• Check the failure reason before escalating.
• Never re-run a check just to investigate it.