Form block
The studio's survey builder: drop in any mix of twelve question types, optionally split them across multiple pages, and read submissions back as per-question rollups instead of a raw list of answers.
How it works
A form is a container block whose children are form field nodes: add as many as you need, in any order, of any type. Twelve field types are supported: text, email, long text (textarea), number, phone, date, dropdown (select), a single yes/no checkbox, multiple choice (radio, pick exactly one), checkboxes (checkbox-group, pick any number), linear scale, and star rating. File-upload questions aren't supported; there's no file-storage infrastructure behind the studio yet.
Single-page forms show in the email in every app: every field, one submit button. The form sends from inside the email only in Gmail on the web and the Outlook apps for iOS and Android, posting directly to the interactions endpoint with no page hop. So every mailed form also shows an always-visible Answer on the web link under it, which opens the same form on the web, unfilled, for readers in every other app.
Multi-page surveys are different in kind, not just presentation. Give any field a page number in its inspector and the form becomes multiPage. A real multi-step wizard needs to carry answers forward across pages, support Back, and give each page its own submit. Static HTML/CSS can't express that — there's no client-side state to track "which page" without JavaScript. So a multi-page form always mails as one Start survey link, styled as a button, in every email app — the same "too complex for CSS" escape hatch the quiz block uses.
The button opens a dedicated hosted wizard route, where each page's answers are saved as an intermediate draft the moment that page is submitted. That's a form-page action distinct from a final submit, so drafts never touch your aggregates, webhooks or CSV until the survey is actually finished. Answers carry forward automatically if the recipient uses Back to revisit an earlier page. Nothing is recorded as a response until the final page's submit; an abandoned survey midway through leaves no partial row in your data, only a draft that's simply discarded.
Configurable fields on the form itself:
- Submit label — the button text for a single-page form.
- Redirect after submit — where the recipient lands post-submission; left blank, it defaults to the live view with a "done" confirmation.
- Background color, padding, border, border radius.
- Field label color/font size, and a submit button color override (text and background).
- Multi-page toggle, and Start survey button label (used only when multi-page is on).
Each form field carries label, field name (the key answers are stored under — keep this stable if you rename the label later), type (the twelve above), placeholder, and choices (for dropdown/multiple choice/checkboxes, as an ordered list). It also carries scale (2–10, for linear scale or star rating), low/high end labels (linear scale only), required, and page (0 = first page; only meaningful once the form is multi-page).
Every submission (single-page or multi-page) lands per recipient in the responses dashboard, and rolls up per question: a bar chart for choice/scale/star-rating questions, and a count plus a capped sample list for free-text questions. See Survey question rollups. The same close date / response cap mechanism poll and rating blocks respect applies here too: a closed form stops accepting new submissions on the live view, mid-wizard or not.
In an email that asks for several answers, this block can count towards a complete response: recipients see how many they've answered, and you see who answered them all. See Collecting an answer to every block. For a questionnaire that should be answered and submitted in one go, one multi-page form is often a better choice than several separate blocks, since it's submitted once, at the end.
Examples
Subject
How was your recent order?
A post-purchase satisfaction survey with five or six questions works well as a single-page form: quick enough to fill in one go. Readers in Gmail on the web and the Outlook apps answer right in the email, and everyone else through the Answer on the web link. A longer intake or application form (ten-plus questions across logical sections — "About you," "Availability," "Preferences") is the natural fit for multi-page mode, so recipients aren't confronted with one long scroll and can return to answers they already gave. See Surveys & NPS feedback for the broader pattern. A course-registration email for a workshop can combine a short-text name/email pair with a multiple-choice "which session works for you?" question, all on one page, feeding straight into a headcount rollup.
What the static fallback looks like
<div id="em-form-1" style="margin:12px 0;background-color:transparent">
<!-- <form> posting to /api/interactions omitted: every field plus one
Submit button. It sends from the email in Gmail on the web and the
Outlook apps for iOS and Android -->
<p style="margin:8px 0 0;font-size:13px;text-align:center">
<a href="https://mailinapp.com/v/eyJhbGci...#em-form-1">Answer on the web</a>
</p>
</div>
For a single-page form, the Answer on the web link under the form is always visible, in every email app, and opens the same form on the web. A multi-page form mails no fields at all, just a button-styled link labeled with its own Start survey text, in every app, since the wizard only ever exists on the live view.