Wakeline
← All features
Collect

Input forms

Capture what you need without a separate tool. Add text, email, select, and multi-line fields to any step — with required-field validation so you always get clean answers.

Tell us about your team
Work email *
you@company.com
Company *
Acme Inc.
Team size
1–10
Submit

Flexible fields

Text, email, dropdowns, and longer text areas.

Required validation

Make key fields mandatory so submissions are complete.

Right in the flow

Collect details inside a modal or step — no redirect, no separate form tool.

how it works

Live in three steps.

01

Add your fields

Choose field types and labels.

02

Mark what's required

Validate before users can submit.

03

Publish & collect

Responses flow into your dashboard.

a real example

A two-field welcome form that segments everything after it.

The first modal is the one moment users will answer anything. Two well-chosen fields there can drive targeting for months — here is the pattern.

01

Ask only what changes behavior

A welcome modal with two selects: "What is your role?" (Founder / Marketer / Engineer / Other) and "Team size" (Just me / 2–10 / 11–50 / 50+). Both required — they are the point.

02

Explain the trade

One line of body copy: "Two questions, and we will point you at the right setup." Users answer questions that visibly buy them something.

03

Route on the answer

The submissions land in Responses, and the answers become the basis for segments — the Engineer path gets the API tour, the Marketer path gets the no-code one.

04

Close the loop

The form's button uses the complete action into a thank-you step that immediately starts the right tour. Never let a form end in silence.

What to expect: A day-one segmentation signal your CRM will not have for weeks. Completion on a two-field required form fired at first login is high; watch it in Responses and cut any field that is not earning its keep.

honest limits

When not to use input forms.

No pattern fits every job. Here’s where we’d point you at something else — sometimes ours, sometimes not.

Data your app already has

Never ask users for what identify() can send — plan, signup date, role from your own database. Every known answer you re-ask erodes trust in the questions that remain.

Sensitive information

Payment details, passwords, government IDs — none of it belongs in an in-product survey form. That data has dedicated, compliant homes; a guidance tool is not one.

Long applications

Three fields is the ceiling in-product. Anything resembling an application or detailed brief belongs in your own product flow, where saving drafts and validation get proper treatment.

questions

Input forms: common questions.

Still stuck? Read the docs or talk to us.

What field types can a step carry?

Text, email, number, textarea, and select — each optionally required. Mix them with survey scales in a multi-step flow: a rating step, then a form step asking why, is the classic pairing.

What does required actually do?

The step will not advance until the field validates — email fields check format, numbers check numeric. You get clean, complete rows in Responses instead of half-filled guesses.

Where do submissions land, and can I export?

In Responses, project-wide and per guide, each submission tied to the user (name or email when identified) with full field values in the table. CSV export gives you the raw rows whenever another tool needs them.

Can form answers drive targeting later?

That is the play: pair forms with traits. Send the durable facts via identify() as traits, use forms for the questions only the user can answer — then build segments on either and route guides accordingly.

Can a form pre-fill what we already know?

The cleaner pattern is not to ask: anything identify() already sent — plan, role, company — should never appear as a question. Keep forms for the answers only the user has, and let traits carry the rest; your completion rate is the direct beneficiary.

See it on your own app.

Ship your first guide in minutes. Free to start — no credit card.