Beacon Campaign / Technical Companion
Form Field Specification
The complete field list for the Beacon campaign contact form, for whoever configures the connection on your side. The visible form is identical no matter which path you choose. Only the hidden plumbing differs, and that part is split out clearly near the end.
Works for both Path A (Web-to-Lead) and Path B (Account Engagement)
What the visitor sees.
Six inputs and a submit button, matching the approved mockup. The "Recommended name" column is what we use internally on Path B. On Path A, Salesforce dictates the names and we wire our inputs to match whatever the generated form produces.
| Field | Input type | Required | Recommended name | Maps to (CRM) |
|---|---|---|---|---|
| Name | text | Required | fullName | Splits into First + Last name |
| Organization Name | text | Optional | company | Company |
| Phone Number | tel | Optional | phone | Phone |
| Required | ||||
| Please choose a topic | select | Required | topic | Custom picklist |
| Marketing opt-in | checkbox | Required | marketingOptIn | Custom checkbox field |
| Submit | submit | n/a | n/a | n/a |
The text beneath the button ("By submitting, your information is sent to Fulgent Genetics...") is static copy. Nothing is submitted from it. The only requirement is that the Privacy Policy link inside it stays live and points to the correct page.
"Name" has to become two fields behind the scenes.
Salesforce requires a Last Name on every Lead, and both Salesforce and Account Engagement store first and last name separately. The mockup collects one "Name" box, so we split it on submit. The visitor still sees a single clean field.
We split on the last space: everything before it becomes First Name, the final word becomes Last Name. A single word goes entirely into Last Name, because that is the field the CRM requires.
"Cher" → First: (empty) / Last: "Cher"
If you would rather not rely on the split, the alternative is two visible inputs, First Name and Last Name. That gives cleaner data but changes the approved mockup. Your call. It is worth a moment because it is your data quality at stake, not ours.
Company is required in Salesforce, optional on the form.
Salesforce rejects any Lead with a blank Company. Organization Name is optional here, correctly, since many visitors are individuals. So when it is left blank, we insert a default value before submitting.
Tell us the exact string to use when Organization is blank. The usual choices are Not Provided or Individual. Whatever you pick will appear in your CRM on every consumer lead, so it is worth choosing deliberately.
This is the single most common reason a form appears to work while no record is created. Settling it now prevents a silent failure at launch.
The Topic dropdown.
The first entry is a non-selectable placeholder. The real options, based on the current live Beacon page, appear to be the four below. Confirm them, and add or remove any you want for this campaign.
- Please choose a topic (placeholder, cannot be submitted)
- Learn more about this product
- Place an order
- Request a test kit
- General question
A picklist stores an internal value that is not always identical to the label the visitor sees. If what we submit does not match a stored value character for character, the CRM silently drops it. Please copy the exact values out of the field definition and send those, so we submit what your system actually expects.
The opt-in checkbox.
A single checkbox that must be ticked before the form can be submitted. The label is your legal-approved wording, dropped in verbatim.
Mechanically it maps to the marketing opt-in field you create in the CRM. When ticked, we submit a positive value (true or 1, depending on the field type). Please confirm whether the field on your side is a true boolean checkbox so we send the right value.
Some teams also store a timestamp and the version of the wording shown, as an audit trail. That is a pair of extra hidden fields and easy to add. It is not in this core spec because it was deprioritized earlier, so this note is here only so the omission is a choice, not a gap.
Hidden fields the visitor never sees.
These carry data the form generates on its own. They are the same regardless of which path you pick.
| Purpose | Field | Value or source |
|---|---|---|
| Attribution | lead_source | Beacon Campaign DigiVidBio |
| First name | first_name | Split from Name |
| Last name | last_name | Split from Name |
| Company fallback | company | Organization, or the default when blank |
| Anti-spam | honeypot | Hidden field that must stay empty |
The part that differs by path.
The naming rules for the connection fields are the one real difference between the two routes. Here they are side by side.
Salesforce dictates the names
The generated snippet defines the field names. We wire our inputs to match whatever it produces.
- oid — your Org ID
- retURL — return URL (a formality, see below)
- 00N... IDs — one per custom field, for Topic and the opt-in
- lead_source and Campaign_ID — supported as hidden fields
We choose the names, you map them
We use the clean names from the visible-fields table. You point each External Field Name at the right Prospect Field.
- email, phone, topic — simple, readable names
- No cryptic IDs to reconcile
- Attribution rides on the Campaign the handler is tied to
- Friendlier to maintain long term
Each path wants to send the visitor to a URL after submitting (retURL on Path A, Success Location on Path B). We post the form to a hidden target instead, so the visitor stays on the page and sees the inline confirmation. That is why we tell you to paste any URL into that field just to get past it.
Optional: richer attribution.
If you want to measure the campaign in analytics beyond a single source label, we can add hidden fields captured from the page URL when it loads. None of these ask anything of the visitor.
| Field | Captures |
|---|---|
| utm_source | Where the click came from |
| utm_medium | The channel (email, paid, social) |
| utm_campaign | The specific campaign tag |
| landing_page_url | The exact page submitted from |
Only worth building if you have fields ready to receive them. Otherwise the data lands nowhere. Tell us if you want these and we will add the mapping to whichever path you choose.
Validation and the states we build.
Handled entirely on our side in Webflow. Listed so you know what the visitor experiences.
Required to submit: Name, Email, Topic, and the opt-in. Email is checked for a real address format, not just for being non-empty. The Topic placeholder cannot be submitted as an answer. We also keep the honeypot and required-field checks on our side, which matters on Path B because a Form Handler accepts whatever is posted to it without validating or filtering spam itself.
