← All help topics

TwinaForms Help

User Verification — one-time code access to sensitive forms.

User Verification gates a form behind a one-time code that's sent to the visitor's email. The visitor's email must match an existing Salesforce Contact — that's how TwinaForms knows it's safe to show or update the right record. Verification happens on the Salesforce side, so the gate is enforced inside your org's own trust boundary.

How it works

When User Verification is on, opening the published form does not immediately show the form. The visitor first sees the User Verification step: a panel asking for their email, followed by a code input. The visitor enters their email; TwinaForms looks it up against Salesforce Contacts; if a Contact is found, a one-time code is sent to that email; the visitor enters the code; and only then does the form render.

The Contact match is the security gate. Visitors whose email is not on any Contact in your Salesforce org cannot pass verification and never see the form, even though the URL itself is public.

Add User Verification

User Verification is a form-level gate shown as a Special Element in the Designer:

  1. Open the form in the Designer.
  2. Under Special Elements, add User Verification.
  3. Select the User Verification block on the canvas to configure its messages and rules.
  4. Republish the form — the gate is enforced at the published-form layer, not in the Draft preview.

The User Verification block represents the gate the visitor will see. It remains fixed at the start of the visitor flow and is not a normal submitted field, so nothing typed inside it is sent into your form's submit actions.

Configure the block

The User Verification block on the canvas is selectable. Click it, and its configuration appears in the right-side Properties panel. This panel is the source of truth for messages, button labels, the Contact-matching rule, and the session duration.

Position note: User Verification protects the whole form, so it remains a form-level gate rather than a freely positioned field.

Session duration

Two session modes are supported per form version:

  • Short session (default) — the visitor stays verified for the duration of the code's expiry window. Refresh the tab and they re-enter their email.
  • Same-tab session — the verified token is stored in the browser's sessionStorage, so the visitor survives a tab refresh without re-verifying. Closing the tab clears the session. The session also expires at the visitor's local midnight, and is capped at 12 hours.

V1 intentionally does not use localStorage, so a fresh browser tab always starts a fresh verification.

Limits & gotchas

  • Verification is enforced on the published form only. The Draft preview does not run the one-time-code step.
  • V1 always uses Salesforce Contact matched by email. Arbitrary-object identity verification (e.g., matching an Account or a custom object) is not supported in V1.
  • If the visitor's email isn't on any Salesforce Contact, the visitor cannot edit the form through User Verification. For situations where Contact/email matching isn't appropriate, remove User Verification and use a create-only flow.
  • Email deliverability depends on your Salesforce email setup since verification runs on the Salesforce side. If visitors say they aren't receiving codes, check spam folders and outbound email configuration in Salesforce.
  • Combine User Verification with the Locked field behavior so prefilled Contact data is read-only on the form — useful when you want the visitor to confirm or update only specific fields.