Contact form
Public forms a customer fills in to open a ticket, and how the fields map onto the ticket.
A contact form is a public form a customer fills in to open a ticket. It is the structured alternative to web chat: you decide what is asked and get the same answers every time. Forms are built at Channels, Contact forms, and building or editing one needs admin.
A workspace can hold several forms. Each is enabled or disabled on its own, and only an enabled form is live.
Building one
Each form carries a title, a URL slug, a description, a submit button label and a success message, plus the fields themselves. The public address is built from the slug on your workspace's help domain, and the builder shows both the link and an embed snippet once the form exists.
Fields come in six kinds: short text, paragraph, email, phone, dropdown and checkbox. Each field has a key, and four keys are reserved because the runtime maps them onto the ticket rather than into metadata.
| Key | Where the answer lands |
|---|---|
email | The customer the ticket belongs to. |
name | The customer's name. |
subject | The ticket subject. |
message | The ticket body. |
Use those four. A form that asks for an email address under some other key produces a ticket with no customer on it and the address buried among the answers. Fields beyond the four can also be mapped onto your workspace's own ticket field definitions, so an answer arrives as a real field rather than as another line of text.
What a submission becomes
Submissions arrive as tickets with the channel Contact form.
Contact form is receive-only
The adapter has no outbound leg, and does not pretend to. A ticket raised from a contact form has its reply composer closed, because there is nothing to deliver a reply into. Follow up by email or on another channel the customer can be reached on. Internal notes work as they do everywhere.