mailinapp
Documentation menu

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 work as a form always has: wherever in-email form posts are supported, the whole form — every field, one submit button — posts directly to the interactions endpoint from inside the email, no page hop. Everywhere else, the form renders as a single call-to-action button that opens the same form hosted on the live view, prefilled with whatever the studio already knows about the recipient from their data-source row.

Multi-page surveys are different in kind, not just presentation. Give any field a page number in its inspector and the form becomes multiPage; because a real multi-step wizard — carrying answers forward across pages, supporting Back, giving each page its own submit — can't be expressed as static HTML/CSS (there's no client-side state to track "which page" without JavaScript), a multi-page form always mails as one link-first Start survey button, regardless of client capability. That's 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 — 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, choices (for dropdown/multiple choice/checkboxes, as an ordered list), 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.

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 inline without leaving the inbox. 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">
  <div class="kn-fallback" style="text-align:center;margin-top:8px">
    <a href="https://mailinapp.com/v/eyJhbGci..."
       style="display:inline-block;padding:10px 20px;background-color:#4f46e5;color:#ffffff;border-radius:6px;text-decoration:none;font-size:14px;font-weight:600">
      Submit
    </a>
  </div>
</div>

For a single-page form, this is what renders wherever in-email posts aren't supported — a button opening the same form on the hosted live view. A multi-page form renders this same button shape year-round, in every client, labeled with its own Start survey text, since the wizard only ever exists on the live view.

Related