Custom Fields in Access Requests

This guide explains how custom fields are shown to visitors, how required fields are enforced, and how we try to auto-fill missing details using safe web search.

What shows up in the modal

• Always ask fields are shown in the request modal immediately. Required ones must be filled before submit.
• Non–always ask fields stay hidden. We first try to gather them automatically (see below). If any required ones are still missing, we’ll prompt the visitor for those specific fields in a second step.
• Fields can target either contacts or accounts. We route answers to the right collection automatically.
• Select and multi-select fields are displayed with your localized option labels.

Auto-filling hidden required fields

We attempt a lightweight web search based on the visitor’s email domain to pre-fill hidden required fields (for example company region or segment). This only runs for required fields that are not marked always_ask.

If the search doesn’t return values for those required fields, the visitor sees a secondary prompt to provide them manually before the request is accepted.

Persistence rules

• Custom field answers are stored when a new account is created from the request. Existing accounts/contacts are not updated.
• Answers are attached to the collection defined on the template (accounts or contacts).
• Required validation happens server-side. Missing required fields will block submission until provided (either upfront or after the secondary prompt).

Visitor flow summary

FAQs

• Can we skip the web search step? Yes—set fields to always_ask to collect them directly in the modal.
• Do we ever update existing records? No. Custom fields are only attached when a new account/contact is created from the request.
• How are languages handled? Field titles and option labels honor your translations; we fall back to English when needed.