Skip to content

Verifying the subject

Verification makes a leaked or forwarded link useless on its own: the subject has to prove who they are before the form will unlock. You choose the mode per request (within what your policy allows).

None : The form unlocks as soon as the link opens. Fine for low-risk internal cases; relies on the link being short-lived and single-use.

Spoken code : A 6-digit code shown only to you. Read it to the subject over the phone or in person — a channel other than the one that carried the link. They type it to unlock the form. A leaked link can’t be used without the code.

Emailed one-time code : A 6-digit code sent to the subject’s email address on the request when they open the link — so the mailbox proves who they are. It’s valid for a short time, and only a few codes can be sent per request. If your organisation allows SMS codes (and the request has a mobile number), the subject can choose to have it texted instead.

Either code : The subject picks whichever suits them at the time: the spoken code or the emailed (or texted) code.

Both codes : Require the spoken code and the emailed (or texted) code. The strongest option.

After a few wrong attempts the request locks — the subject is told to ask you for a new link — and you (the requester) are alerted. This stops a leaked link being brute-forced.

  • Phone contact already happening? Use the spoken code — it piggybacks on the call you’re already making.
  • Can’t reach them live? Use the emailed one-time code so the mailbox proves identity.
  • Not sure how you’ll reach them? Either code lets them choose.
  • High-value credential, or an external subject? Require both.

Your org can set a minimum that every request must meet — see Setting your policy.

The verification step appears above the form on the handoff page, with your branding and contact details, so they can confirm the request is genuine before entering anything.