
This playbook covers applicants completing identity verification in a web browser on a phone, tablet, or computer. Web invite links take the form:
cognition.cerebrum.com/vid/i/<invite token>
If the applicant is using the vID mobile application instead, use the mobile playbook. The two experiences behave differently and share only some of their failure modes.
How to tell which one they are using. Ask: "Are you completing this in a web browser like Chrome or Safari, or in an app called vID that you downloaded?" If they are unsure, ask whether they see a browser address bar. The answer changes the guidance.
Asking these first will resolve or correctly route most contacts.
What device and browser are you using?
Where exactly in the process are you — email verification, ID scan, or selfie?
What does the screen say? Ask them to read the message verbatim rather than paraphrasing.
Are you on a work computer, a work network, or a VPN?
Record the answers. If you end up escalating, Cerebrum needs these four items, plus the invite or order ID, to investigate.
Never ask an applicant to email, text, or otherwise send you images of their ID or a selfie. If a support workflow requires collecting identity documents outside the verification flow, that is a data handling decision with privacy and security implications — establish it with your legal counsel before adopting it, and do not improvise it on a live contact.
Do not tell an applicant they failed, were rejected, or were flagged for fraud. Verification outcomes are determinations your organization makes, not something support conveys mid-process. Describe what needs to happen next, not what the system concluded.
What is happening: The applicant needs an emailed code to verify their email address before entering the flow. The email has not reached them, or has been filtered.
What to do:
Confirm the email address they are checking matches the one on the invitation exactly. Typos and personal-versus-work address mismatches are the most common causes.
Ask them to check their spam, junk, and quarantine folders. Corporate mail filtering routinely holds these.
If they use a work email address, ask whether their organization quarantines external mail. If so, a personal address is usually faster than fighting the filter.
Have them request the code again from the verification screen.
If it still does not arrive: escalate with the applicant's email address and invite ID so delivery can be traced.
What is happening: Usually, the applicant reached the vID web service without the full invitation link. This happens when they navigate to the site directly, use a bookmark, or recover their account by email rather than opening the original invitation. The session has no invite attached, so there is nowhere to send them.
What to do:
Ask them to close all open vID and Cerebrum browser tabs.
Send them the original invitation link again, or a fresh one, and ask them to open it directly from the email rather than typing the address or using their browser history.
Ask them to open the link in the same browser they will use to complete the flow.
If they previously created an account and were prompted to recover it, have them complete recovery first, then open the invitation link again.
Note: if the applicant is on a phone with the vID app installed, a standard invitation link may redirect them into the app. If you need to keep them in the browser, request a web-only link — see Scenario 9.
What is happening: The browser does not have camera permission, another application is holding the camera, or the browser or device does not support the capture.
This is the single most common vID Web contact. Work through the list in order.
What to do:
Check permissions. In Chrome and Safari, the site permission prompt appears once. If the applicant dismissed or blocked it, it will not reappear on its own.
iPhone, Safari: Settings → Safari → Camera → Allow, then reload the page
Android, Chrome: tap the icon at the left of the address bar → Permissions → Camera → Allow, then reload
Desktop, Chrome: click the icon at the left of the address bar → Camera → Allow, then reload
Desktop, Safari: Safari → Settings for This Website → Camera → Allow
Close other applications using the camera. Video conferencing tools are the usual culprit and will silently hold the camera.
Reload the page after changing any permission. Permission changes do not take effect on the current page load.
Try a different browser. Chrome and Safari are the most reliable. In-app browsers — links opened from inside a messaging, social, or email app — frequently block camera access entirely. If the applicant opened the link from within another app, have them copy the link into a real browser.
Switch devices. A mobile phone generally produces better results than a laptop webcam.
If the device genuinely has no working camera: the applicant cannot complete verification on it. Direct them to a phone or tablet. If no device with a camera is available to them, escalate — a package configuration change may be possible, but that is a decision for your organization, not something support should promise on a call.
What is happening: The scan cannot extract readable data. Browser-based capture is more limited than the native app — most mobile browsers do not support tap-to-focus, so blur is more common in the web flow.
What to do — coach them through a better capture:
Bright, even light. Avoid overhead light directly above the ID, which creates glare.
Flat, dark, non-reflective surface. Not a lap, not a hand, not a glossy countertop.
Fill the frame, all four corners visible.
Hold steady for a beat before the capture fires.
Remove the ID from any plastic sleeve, wallet window, or holder.
Capture the front and the back.
If the browser capture keeps failing: suggest they restart the flow on a mobile phone, or complete it in the vID mobile application, where the native camera produces materially better results. See Scenario 9 for how to move them between experiences.
After two failed scan attempts, the applicant is routed to manual data entry rather than being blocked. This is intentional and keeps them from getting stranded. Tell them it is fine to proceed — but note that orders completed through manual entry go to manual review by design, since the automated checks could not run against extracted document data. Set that expectation so they are not surprised by a delay.
What is happening: Camera permission, lighting, framing, or a liveness failure.
What to do:
Rule out camera permission first — see Scenario 3.
Coach the capture: face the camera directly, even front-facing light, no backlit window behind them, no sunglasses or hat, neutral expression, follow the on-screen prompts and hold still.
Do not hold the ID up beside or in front of the face. The selfie and the ID are separate steps. Holding both in frame is a frequent cause of a later flag.
If they are on a laptop with a poor webcam, move them to a phone.
If the applicant cannot present an unobstructed facial image — for medical, disability, or religious reasons — do not improvise. An alternative package configuration that bypasses the selfie step may be available, but whether to offer it is a policy and accommodation decision for your organization. Escalate internally first, and confirm your approach with your legal counsel, since accommodation obligations vary by jurisdiction and employment context.
What is happening: Could be a transient service error, a session problem, or an integration fault. The specific message matters.
What to do:
Ask for the exact error text and a screenshot.
Check status.cerebrum.com for a known incident before troubleshooting further.
Ask them to reload and retry once. Many submission errors are transient.
If they retry and it succeeds, confirm no duplicate order was created before closing the contact.
Errors worth recognizing:
What they see | Likely meaning | First action |
|---|---|---|
A page that will not load or spins indefinitely | Transient service error | Check status page, retry once |
An access or permission error | Account or session mismatch | Confirm they opened the original invite link; see Scenario 2 |
A generic server error on submit | Service-side fault | Escalate with invite ID and timestamp |
Do not have the applicant retry more than twice. Repeated submissions can create duplicate orders, which then need cleanup. Escalate instead.
What is happening: The invitation lapsed before the applicant completed it. Invitations are valid for 30 days by default and are configurable at the package level.
What to do:
Confirm the expiry in your system before acting — sometimes the applicant is looking at an older invitation from a previous attempt.
Issue a new invitation.
If expired invitations are a recurring problem for a particular client, the expiration window can be extended at the package level. Raise it with your account contact rather than reissuing repeatedly.
What is happening: The submission completed but did not clear automatic approval, so it is awaiting review. This is normal and is not an error.
What to say: Their verification was received and requires an additional review step. It does not mean anything is wrong, and there is nothing further for them to do right now.
What not to say: Do not tell them they passed, failed, or were flagged. The determination has not been made, and it is not support's to convey.
Internally: the order will appear in Cortex with a Pending status and score. Your review team resolves it. See the vID Alert-to-Action Matrix.
Two link types behave differently, and knowing which one you sent prevents a lot of confusion:
Link type | Behavior |
|---|---|
Standard invite link | Routes to the vID mobile app if the applicant has it installed; otherwise opens the web flow |
Web-only invite link | Always opens the web flow, regardless of whether the app is installed |
If an applicant keeps getting pulled into the app and you want them in the browser: request a web-only link. Sending the standard link again will produce the same redirect.
If an applicant is struggling with browser capture quality: the mobile application uses the native camera and generally produces better scans. Note the constraint below before redirecting them.
Constraint worth knowing: the mobile application is not designed to accept single-use invitations. If your integration issues one-and-done invites, the web flow is the correct path for those applicants, and routing them to the app will produce an error. Confirm how your integration generates links with your technical team before changing what you send.
What is happening: Corporate networks and managed devices interfere in several ways — VPN and proxy connections raise flags on the submission, managed browsers block camera access, and corporate mail filtering holds verification codes.
What to do: Ask them to complete verification on a personal device connected to their home internet, with any VPN turned off. This resolves camera permission problems, connection-based flags, and code delivery problems in one step, and it is worth suggesting early rather than after working through the rest of the list.
Escalate when: you have worked the relevant scenario without resolution, an error recurs across retries, you suspect a service fault, or the applicant is blocked with no workable device.
Submit through the support portal at portal.cerebrum.com/support and include:
Invite ID (VID-…) or order ID
Applicant email address
Device, operating system, and browser
Exact error text and a screenshot
Timestamp of the failed attempt, with time zone
What steps you have already tried
Whether the applicant was on a corporate network or VPN
Escalations without the invite or order ID cannot be investigated and will come back to you for it.
Check status.cerebrum.com before escalating a suspected platform-wide issue.
Symptom | First thing to try |
|---|---|
No verification code | Spam and quarantine; confirm the address matches the invite |
404 or dead link | Close all tabs; reopen the original link from the email |
Camera not working | Browser permission, then reload; avoid in-app browsers |
ID won't scan | Flat dark surface, even light, no sleeve, fill the frame |
Selfie won't work | Camera permission; separate the selfie and ID steps |
Error on submit | Status page, then one retry; capture exact wording |
Invite expired | Confirm, then reissue |
"Nothing happened" | Normal — additional review; no applicant action needed |
Keeps opening the app | Request a web-only link |
Work laptop problems | Move to a personal device on home wifi, VPN off |
This playbook is operational guidance for support teams. It does not constitute legal advice. Decisions about accommodating applicants who cannot complete standard verification, about collecting identity documents outside the verification flow, and about what is communicated to an applicant regarding a verification outcome should be established with your legal counsel.