Troubleshooting
Most verification problems are a handful of causes. Working through them in order of likelihood resolves the great majority without contacting a provider.
Where to find it
Architect Panel → Security:
- User Verification — the console — providers, types, checks and their history
Architect Panel → Activity:
- E-mail Log — whether a domain-check message was sent
- Error Log — technical failures around a check
Start with the record
Open the check and read the status, the failure reason and the event history before anything else. It usually contains the answer, and every other step is slower.
The link expired
The commonest failure on domain checks. The user received the message, came back later, and the link had timed out.
Fix for the individual: re-run the check. Fix for the pattern: lengthen the link timeout on the type. If this happens often, 30 minutes does not suit how your users read e-mail.
The message never arrived
Check the e-mail log. If it shows a successful send, the message left and the problem is at the recipient's end — a corporate filter, a full mailbox, a typo in the address they gave. If there is no entry, the check never got that far.
The domain is not accepted
The user's address is at a domain the type does not list. Read the type's domain list against the address carefully — a wildcard covering *.nhs.uk does not cover nhs.net, and that specific pair catches people out.
Decide whether to add the domain or route the user to another verification type. Do not add a domain casually — it grants everybody at that domain the same result.
The document check failed
Read the failure reason. Poor image quality, an unreadable document and a mismatch are different problems with different advice. Repeated failures with no clear reason are worth raising with the provider — quoting the provider reference.
Remember that legitimate failure is common. Somebody failing twice is not evidence of fraud; it may be a worn licence and a bad camera.
Verified, but access has not changed
Check three things in order: has the check expired; does the type actually award a group; and does that group have the access the user expects. Most of these turn out to be the third — the verification worked and the group does not grant what somebody assumed.
Nothing happens when a check is started
Check whether the provider is enabled, whether its credentials are present, and whether it is in sandbox when you expect production. A provider left in sandbox after commissioning is a classic, and it produces results that look real but are not.
The same user appears twice
Look at the three-part identity. The same person arriving by two different sign-in routes is two identities, and a verification against one does not apply to the other. This surfaces when somebody moves from a local account to single sign-on.
Worked example
A run of failures on the clinician type all show "domain not accepted". The users are at nhs.net, which the type had lost when its domain list was edited. Adding it back resolves everybody at once, and the event history confirms the change coincided with the edit.
Recommendations
- Read the check record first, every time.
- Lengthen the link timeout if expiry is a pattern.
- Confirm sandbox is off after commissioning.
- Check the identity route when a verification seems to have vanished.