Website forms
Build forms in SmileLine, confirm the forms detected on your website, and manage every enquiry endpoint from one list.
Settings → Website is one list of every route an enquiry takes from your website into SmileLine. By the end of this page you'll know how to build a form, confirm a detected one, and manage mapping, deliveries and lifecycle for all of them.
Three kinds of form
| Type | How it starts | What it is |
|---|---|---|
| Built in SmileLine | You build it with the form builder | Gets a hosted page and an embed snippet; every field maps automatically. |
| Detected on site | The tracking script finds it | A form that already exists on your website. Confirm its field mapping once and SmileLine captures every submission — no website changes. |
| Custom endpoint | You create it for your own code | A raw capture endpoint your form, backend or third-party tool posts to. Set up in three steps: basics, one test submission, confirm the mapping. See Custom integrations. |
The list shows each form's type, status and when its last lead arrived. Statuses:
- Needs mapping — a detected form awaiting your confirmation, or a custom endpoint listening for its first submission. Submissions park safely in the meantime; nothing is lost.
- Active — capturing submissions and opening journeys.
- Paused — intake stopped without deleting anything.
- Archived — retired; shown under the Archived view with a restore icon.
Build a form in SmileLine
Click New form and choose Form builder — "Build the form here. You get a hosted page and an embed, and every field maps automatically."
Add fields — Text, Email, Phone, Long text or Checkbox, up to 30. Each has a label, a field key (derived from the label until you edit it), and a Required toggle. Field keys double as the submitted payload keys, and the capture mapping is re-derived automatically when you edit them.
Leave Default treatment set to None for a general enquiry form, or choose a fallback treatment. If the submission matches a treatment, Smileline opens its journey; otherwise it uses the default. With neither, a new contact appears as an enquiry in Today for your team to triage. You can also choose a location and a Lead source if the submission has no attribution. A submission that arrives with campaign parameters picks its own source — matching your list by name or adding a new one — as described in How the lead source is chosen; the one you pick here is used only when it carries none.
Set the submit button text and the success message, then create the form.
Put it on your website
Open the form's Hosted page tab:
- Share the hosted page — a standalone page on SmileLine's domain showing your practice name, brand colour and the form:
https://widget-eu.smileline.io/form/?key=YOUR_FORM_KEY(US practices receive awidget-usaddress). Link to it from anywhere — ads, emails, QR codes. - Embed it — copy the
<iframe>snippet from the same tab to place the form inside an existing page. Embedded, it renders transparent so it sits naturally in your design. - The Hosted page live switch takes the page offline without touching the form itself.
Hosted forms carry bot protection: an invisible honeypot field, and a Turnstile challenge where configured. A submission that fails these checks is never silently dropped — it is recorded or parked for review.
Confirm a detected form
When the tracking script finds a form, it appears in the list as Detected on site with the status Needs mapping. Once somebody submits it, a Detected form row appears in the review queue showing how many submissions are waiting for the mapping. Detection reports only field names, labels and input types — never anything a visitor typed. Login, search and password forms are skipped.
A detected form is identified by your website's host and its field names, so a form that appears on every page — a header call-back form, a footer newsletter, a quiz embedded on several landing pages — is one row, shown with the page the script last saw it on. Archiving a detected form keeps it archived: later scans refresh it quietly and never list it again.
A pending form is already being captured: its submissions are stored safely until you confirm, and confirming replays every one of them into the CRM. Archiving the form instead deletes them — see Pause, archive and restore.
If your website already posts a form to a custom endpoint, the script still detects it. Archive the detected copy from Settings → Website rather than confirming it — confirming both would create every lead twice.
Open the form. The Confirm the field mapping card shows a proposed mapping — badged AI proposal or Suggested from names. Click New proposal to recompute it, ideally after a test submission has arrived so the proposal can check itself against real data.
Submit the form on your own website once, as a test. The submission appears on the card so you can see each mapped value resolve.
Review the mapping — first name, last name, email, phone, treatment, location, message and marketing consent. Default treatment is optional: leave it as None to receive new contacts without a matching treatment as enquiries in Today.
Click Looks right — activate. The form goes live and every submission that was waiting is replayed into the CRM as a lead.
Confirmation replays every submission that was waiting for the form, however long it has been pending. One that still cannot be processed — no usable email or phone, for example — stays in the review queue as its own row, where you can Retry it.
If a detected form's website page also posts to a SmileLine custom endpoint (or a third-party tool that forwards to one), the same enquiry can arrive twice — once from your integration and once from the script. Patients are deduplicated by email and phone, so no duplicate patient is created, but you should pick one capture route per form and retire the other.
Field mapping
Every active form has a Field mapping tab that controls which incoming field fills which patient field. Each box takes an exact field name (email) or a dot path into a nested payload:
data.contact.email
answers.0.valuePaths address nested objects by key and lists by position, counting from zero. A field whose name literally contains a full stop still wins over the path, so existing mappings keep working.
A custom endpoint's first mapping is proposed from its first submission when you create it (see Custom integrations). To refine any active form later, pick a representative delivery on the Deliveries tab, then switch to Field mapping: the payload's fields are listed beside the boxes, and clicking a field drops its path in. A box that names a field is green with a tick, and that field carries a green chip in the payload list, so an unmapped box is easy to spot. The preview resolves phone numbers, treatments and locations exactly as intake will, and warns when a path points at a group rather than a value or a value will fall back to the form's default. Saving applies to the next submission — deliveries already received are not reprocessed.
Attribution (utm_*, gclid, fbclid, landing_url, referrer) is never mapped — it is read automatically from the page's query string, from fields of those names anywhere in the payload (nested objects included, with the shallowest one winning) and from an _sl.url_params envelope. The Attribution · captured automatically group at the end of the mapping says so in place, and the payload list keeps those fields under Captured automatically, marked Automatic, where they cannot be clicked into a box. The Attribution block at the top of the selected delivery shows which parameters arrived, their values, and the channel and lead source they produced — so a form that has been booking every lead as direct is visible without opening a lead. See Attribution.
What you can map
The boxes are grouped by what they fill on the patient record.
| Group | Fields |
|---|---|
| Contact | First name, Last name, Email, Mobile, Telephone |
| About the person | Date of birth, Gender, Address, Address line 2, City, County, Postcode, Country |
| Preferences | Preferred contact method, Preferred contact time, Marketing consent |
| Enquiry | Treatment, Location, Message, Additional info |
Most are stored exactly as they arrive. Four are interpreted:
- Mobile and Telephone are read against the location's country, so
07700 900123and+44 7700 900123both store the same number. - Date of birth takes an ISO date (
1985-03-12) whatever your country. A slashed date is read day-first for a UK practice and month-first for a US one, following the location on the submission. - Gender accepts the usual spellings (
M,Male,F,Female,other,prefer not to say). - Preferred contact method accepts
phone,call,sms,text,emailorwhatsapp.
A date, gender or contact method none of these can read is left empty on the patient rather than stored wrong — and, like every field you did not map, it is still kept: the whole submission is listed as submitted answers on the lead, so nothing a visitor typed is lost. A phone number or email address is different: it is always stored on the patient, as typed when it cannot be read.
Message is the enquiry and lands on the lead's timeline. Additional info is the standing note on the patient record, and a second enquiry adds to it rather than replacing it.
Additional fields
A form often asks things no box above covers: an eligibility quiz's answers, how soon someone wants to start, whether they are interested in a payment plan. Those answers are what a caller needs at hand to qualify the lead, and the submitted-answers card buries them among the form's own plumbing.
Under Additional fields, add a row per answer you want on the enquiry itself: the incoming field (or dot path, exactly as above) and the label a caller should see. With a delivery selected, click a row's field box and then the field in the payload beside it; a blank label is filled in from the field name and can be edited. Up to 20 rows per form.
Each mapped answer lands on the enquiry as label: value, shown under Additional information on the lead in Today and on the enquiry in the patient's journeys. They belong to that enquiry: a second submission from the same person opens its own enquiry with its own answers, and never changes the first. An answer you have mapped here is not repeated on the submitted-answers card; everything else still is.
A submission with no matching treatment and no default opens no treatment journey. A new contact appears as an enquiry in Today; its answers stay on the submitted-answers card until it is triaged. An existing contact keeps their current status and history.
Returning enquirers
When a submission matches someone the practice already has, the mapped fields fill in the blanks on that record and never overwrite what is already there — a form can add the postcode you were missing, but it cannot move a patient to a new city because a visitor mistyped it. Correct an existing value on the patient record itself. The submission still opens its treatment journey, and if that person was already waiting in New · Call now their card moves back to the top of Today as one fresh card rather than a duplicate.
Phone numbers and email addresses
A submission needs at least one contact detail: an email address or a phone number. A phone is read in the ways people actually write one — 07700 900123, +44 7700 900123, +44 (0)7700 900123, +44 07700 900123, 44 7700 900123, a tel: prefix, and an extension or note after the number (ext 4, x4, (mobile), a trailing comma). When a detail cannot be read — a mistyped email, a phone no rule matches — the lead is still created and the value is stored on the patient exactly as typed (it is also kept on the delivery); an unreadable phone additionally opens a Contact could not be read item in Intake review, where Fix phone corrects the patient's record.
Delivery history
Open a form and choose Deliveries to see what it has actually received. Every entry can be selected to inspect the exact payload that arrived.
| Entry | What it means |
|---|---|
| Accepted | The submission became a lead. Selecting it shows the complete field set SmileLine received. |
| Rejected | A live form turned the submission away — malformed JSON, a bad signature, a filled honeypot field (a bot), or neither an email nor a phone at all. The reason and the offending body are both kept. In the rare case that the review queue's daily ceiling for suspected-bot or unpinned-domain submissions is exhausted, further ones are recorded here too (as turnstile failed or unpinned domain) instead of being lost. |
Repeated failures of the same shape are grouped into one entry with a count and a last seen time, so a backend stuck in a retry loop reads as "Invalid JSON × 10,432, last seen 2 minutes ago" rather than thousands of identical rows.
Rejected bodies are kept for 13 months and then redacted; the entry, its reason and its counts remain. Accepted deliveries keep their payload for as long as the lead exists.
Submissions turned away before SmileLine identified the form — an unknown or regenerated endpoint, a paused or archived form, an oversized body, or a rate limit — are not recorded here. Neither are re-sent deliveries that reuse an earlier delivery ID: those are answered from the original result without creating a second lead or a second entry.
Pause, archive and restore
- Pause stops intake without deleting anything. A paused form's endpoint and hosted page answer
404until you resume. A form that still Needs mapping cannot be paused: confirm its mapping or archive it. - Archive retires the form for good while keeping its history and attribution. Its endpoint stops working immediately, and any submissions still waiting for its field mapping are permanently deleted.
- Restore (from the Archived view) only un-archives — a form that was paused before archiving comes back paused, and deleted submissions do not come back. A form that still needs its mapping returns to the review queue with its next submission.
Archiving a form that still Needs mapping permanently deletes every submission waiting for it, and Restore brings the form back but not them. If any of them might be a real enquiry, open the form first — its newest waiting submission is shown as the mapping sample — and confirm the mapping instead.
If a form's default treatment, location or fallback lead source was archived before a submission arrived, SmileLine still preserves the lead and opens an intake-review item rather than losing the enquiry.