Collecting something from people, and deciding what happens to it. A form can open a ticket, create a contact, start a deal, put an applicant on a hiring board, or simply keep the answers.
For how it is built — the model, the public flow, the builder API — see Forms architecture.
Starting from a template#
Seven templates ship: bug report, feature request, support request, contact us, lead capture, feedback and job application. Each one arrives with sensible fields already on it, which is usually faster than starting blank and always faster than arguing about what to ask. The job application template also arrives connected to Hiring — see Hiring.
A form is active or not. Inactive means the public link stops answering — which is how you take a form down without deleting the answers it already collected.
Building it#
Fields are dragged into order; each has a type, a key, and whether it is required. The tabs across the top are the part worth knowing about, because they are where a form stops being a survey:
| Tab | What it decides |
|---|---|
| Appearance | How the public page looks |
| Thank You | What the person sees after submitting, or where they are sent |
| Connections | What each submission creates: a ticket, a CRM record, a deal, a hiring candidate |
| Automations | Anything else that should happen |
| Submissions | Everything collected so far, and what each one created |
Connections#
Everything a submission creates is set up in one place. Add connection, pick what to create, then:
- Settings for that kind of record — the ticket's team and assignee, the CRM object, the deal's pipeline and stage, the job an applicant applies to.
- Field mapping, the same table for every connection: each question on the form, and which field of the record its answer fills. The contact block's name and email can be mapped too.
A form can have several connections. A lead-capture form that creates a contact and a deal is one form with two connections, not two forms; the deal is linked to the contact whichever order they are listed in.
Each connection can be switched off without losing its settings.
Hiring candidate. Each applicant goes into the talent pool and gets an application on the chosen job's board, in its first stage (or the stage you pick). Somebody who applied before is recognised by email: their details are updated where the new answers fill a gap, and they get a new application rather than a duplicate profile. If they already have an open application for the same job, their answers are added to it. A file-upload question can be mapped to Resume, and the answers are kept on the application as the applicant gave them, even if the form changes later. If the job's first stage has an assessment set to send automatically, applicants receive it straight away.
The public page#
Every form has its own link and needs no account behind it. Anyone with the link can fill it in; the answers arrive in the workspace.
If you need to know the address is real, set the form to verify it — the person gets a code before their answers are accepted. Weigh it honestly: it stops rubbish, and it also stops some genuine people.
Rules that show and hide fields#
Conditional rules make the form react — ask about the plan only if they said they are a customer, and so on.
A hidden field is not a validated field. Hiding removes it from the page, not from what the server will accept. If something must be present, make it required and give it validation; conditional rules are for the experience, not for the data.
When part of it fails#
A submission that arrives but whose downstream steps do not all succeed is recorded as partially failed — and the person who submitted it still gets a success page, because their part worked.
That is the right behaviour and a quiet one: nobody is told that the CRM record was not created. Check the submissions list, which shows what each connection did with each submission — created, failed with the reason, or skipped (an applicant who already had an open application for the job) — before assuming a form has been working all month. A connection that fails leaves the others alone.
Common mistakes#
- Creating tickets with nowhere to send them. A ticket connection with no team leaves tickets unassigned in the queue.
- A job application form with no email. An applicant is recognised by email; the hiring connection refuses a submission without one. Keep the contact block's email on.
- Trusting conditional rules to enforce data. They do not.
- Assuming a green page means everything worked. Partial failures are visible only in the submissions list.
- Deleting a form to take it down. Switch it inactive; the link stops answering and the answers survive.
- Using a public form for a bulk import. The public endpoint is rate limited per address, deliberately. Importing your data is the other path.