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.
→ User verification for Salesforce forms — the overview, use cases, and how it compares to other form tools.
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:
- Open the form in the Designer.
- Under Special Elements, add User Verification.
- Select the User Verification block on the canvas to configure its messages and rules.
- 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.
Session duration
Set Verified Session Length per form version:
- Short (default) — the visitor is asked again after 15 minutes without activity, or after 1 hour. Refresh the tab and they re-enter their email.
- 4 hours — the session survives a page refresh in the same browser tab, with no inactivity limit, and ends 4 hours after the code.
- Until midnight — the same, until the visitor's local midnight (never more than 12 hours).
The longer modes keep the session in the browser's sessionStorage, so closing the tab ends it and a new tab always starts a fresh verification. Choose them only for forms used on a trusted device.
One verification across several forms
When your forms link to each other — a hub form with Buttons that open other forms, or a form whose post-submit link opens the next one — a visitor can verify once and move between them without a second code.
- Set Verified Session Length to 4 hours or Until midnight on every form in the journey.
- On each form that people arrive at, tick Accept verification from forms that link here in the User Verification settings.
- On the form people come from, add a Button whose destination is the other form (or use it in the post-submit link). Publish the receiving form first, then the form that links to it.
A verified session is passed only along those links, only inside your own Salesforce organization, and never lasts longer than the first code. The receiving form still applies its own rules: a form that needs an existing Contact will not accept a visitor who verified with an email address that has none. A link opened in a new tab asks for a code again.
Add a Button with the destination Sign out to any form where people should be able to end their session. It ends the session on every form of the journey, and the next visitor on that computer must verify again.
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.