Lead forms and guardrails

The three layouts

A lead form is a set of fields plus a decision about how the visitor is asked for them. You build the fields at Leads -> Forms; the layout is chosen on the widget, under Lead capture.

That split is deliberate. The questions are usually the same everywhere -- name, email, what they need -- while the right way to ask depends on where the visitor is standing. A chat bubble on a pricing page and a full-page assistant on your own subdomain can share one form and ask for it two different ways.

• Inline. Every field at once, inside the chat panel. The right choice for two or three fields.
• Step by step. One question per screen with a progress indicator. Better for a longer form, because a visitor who sees eight boxes at once usually closes the panel.
• In the chat. No form is shown at all. The assistant asks for the details in conversation, one or two at a time, while it answers the visitor's own questions.

Each option shows a live preview of itself, so you are choosing a behaviour rather than a word.

The stored lead is identical whichever you pick. A name asked in conversation lands in the same two columns a submitted form fills, a dropdown answer is still checked against its options, and a hidden field still takes the value you configured.

The form still owns everything else: the fields, their order, the wording, the consent sentence, the thank-you and the guardrails. A widget that has never chosen a layout follows the form's own, and the Layout card says so by name.

What is different about In the chat

There is no submit button, so there is no moment where everything arrives at once. Each answer is saved as it is given. Somebody who leaves after two questions leaves a real lead with two real answers on it, marked Partial in the leads list with a Chat trigger.

A partial lead becomes a normal one by itself the moment the last required field arrives. An optional question left unanswered does not hold it back.

Two consequences worth knowing:

• The assistant never asks twice for something it already has, including a week later in a new conversation. It is told what is already saved on every turn, so this does not depend on the transcript still being in its context.
• Your Consent text is spoken rather than shown. A conversation has nowhere to put a checkbox, so the assistant says the sentence before it asks for contact details.

Guardrails

Guardrails are the rules the assistant follows while it answers. They live in two places and the second one only exists to disagree with the first:

• Settings -> Guardrails is the workspace rule. Every knowledge base and every lead form runs under it unless it says otherwise.
• The Guardrails card on a form shows exactly what that form will do, and can replace the workspace rule for that form alone.

A new form always starts under the workspace rule and picks up any later change made there. Turning on Give this form its own rules takes a full copy and stops following: from then on, changing the workspace rule does not change this form.

The replacement is the whole policy, not a patch. If the workspace blocks a topic and this form does not, the topic is no longer blocked here. That is deliberate -- a half-inherited policy is one nobody can read off the screen.

Two rules you cannot switch off

Every assistant in every workspace follows these, and no setting removes them:

• It answers only from your knowledge base. If the material does not contain the answer, it says so and offers what the visitor can do next. It does not fall back on general knowledge, and it does not invent a price, a date or a policy.
• It never shares a credential it finds. If an API key, a token, a password, a cookie or a private key is sitting in one of your documents, it is removed from the material before the assistant reads it -- so there is no version of the question that gets it back out. The assistant is also told not to explain how to exploit a weakness in your systems.

The second one is worth reading twice: it is enforced, not requested. That is the difference between an instruction a clever visitor can argue with and a value that is not there to be repeated.

What you can change

Check the rules before you publish

Open See the instructions the assistant is given on the Guardrails card. That is not a summary -- it is the literal text the model receives, in order. Read it, then press I have read these rules.

The warning comes back whenever the rules change, including a change made at the workspace level that this form inherits. A tick that refers to text nobody has read is worse than no tick at all.

Phone numbers

A Phone field asks for the country as well as the number. The visitor's own country is picked to start with, and typing or pasting a dial code moves it: +12035124414 becomes the United States flag and 203 512 4414 in the box. The country list is searchable in the visitor's own language.

The answer is stored in E.164 -- +12035124414 -- whether the visitor typed spaces, brackets or neither, so every CRM this forwards to receives one dialable shape.

Where the visitor came from

Every form captures the origin of the visit by default: the UTM tags, the advertising click ids (gclid, fbclid, msclkid, ttclid, li_fat_id and the rest), the referrer and the page they landed on.

It is first touch, and it lasts 30 days. Somebody who arrives on a Google ad, reads three pages and then opens the chat is still that ad's lead -- the page they happened to be on when they typed says nothing about who paid for them.

You can see it on the lead itself, under Where they came from, and every one of those values is a mapping source in Destinations, so utm_campaign can land in a CRM column of its own.

Turning it off

Under Submission, the switch Capture where the visitor came from is on by default. It is on by default because those parameters exist for one page view and then the visitor navigates and they are gone for ever -- there is no going back for them later. Turn it off and the widget collects nothing and forgets whatever it had already stored for that visitor.

Attaching a form to a widget

A form does nothing until a widget uses it. Open the widget, go to Lead capture, and pick it -- then pick the layout you want on that widget. One form can serve several widgets, each asking in its own way; deleting a form that a widget still uses is refused, and the message names the widgets.

Troubleshooting

The assistant is not asking for anything. Check three things on the widget's Lead capture tab: that Enable lead capture is on, that the widget is pointed at this form, and that its Layout is In the chat. In Inline or Step by step the form is only shown when the assistant decides to show it, or when a visitor uses a quick action.

Lead capture is off and a form still appeared. It cannot any more. Switching it off now removes the tool from the model entirely, and the assistant is told not to offer a callback it has no way to record.

It asked for something the visitor already gave. Look at the lead row: if the answer is not stored, it was rejected by validation -- a dropdown answer outside its options, or an address that is not one. The assistant is told to ask again for exactly those.

It answered something off-topic. The workspace rule may be off, or this form may have replaced it. The Guardrails card on the form says which, in one badge at the top.