Skip to main content
Browse documentation

Fronty documentation

Create forms and manage submissions

Build and validate a form, choose where responses go, and prove that a submission from the published origin reaches the intended destination.

Last verified

Availability

Limited

Forms and submissions exist, but sites enrolled in immutable releases are blocked until origin-bound form capability is complete.

Plans
Form availability and quotas depend on the active plan and release mode.
Roles
An editor can build a form; submission access and configuration require the corresponding website permission.
Before you start
A website, a defined purpose for the form, and a privacy basis for every field collected.
On this page
  1. Define the form before adding fields
  2. Build and validate the form
  3. Choose and verify destinations
  4. Test from the published origin

Define the form before adding fields #

Name the decision or workflow the response supports. Collect the minimum data needed to complete that purpose. Decide whether replies belong in the dashboard inbox, a database table, an email notification, or more than one destination.

Write the success state and privacy explanation before styling. File uploads, marketing consent and sensitive personal data require deliberate retention and access rules; do not add them simply because the field type exists.

Build and validate the form #

  1. Add a Form component in the editor or describe the required form to the AI builder, then review every generated field.
  2. Use the field type that matches the answer: email for email, date for a date, radio or select for one controlled option, and checkboxes for several.
  3. Give every input a visible label. Placeholder text is an example, not a label.
  4. Mark only genuinely required fields as required and provide an error that explains how to fix invalid input.
  5. Add conditional logic only when it shortens the form. Test both the condition that reveals the field and the path that keeps it hidden.
  6. Set a clear success message or a valid redirect destination.

Choose and verify destinations #

Dashboard submissions provide the central inbox. A database destination creates a row that can drive another workflow or page. Email notifications are a convenience, not the source of truth: delivery can be delayed or dropped by an email provider, and the Go service's notification queue is best effort.

When mapping to a table, match each form field to a compatible column type. Do not publish a form that writes into a table you later expose publicly unless the public page deliberately filters sensitive fields.

The public endpoint currently accepts at most 20 collected answers, a 16 KB payload, and 1,000 characters per value. It rate-limits repeated traffic and drops sensitive-looking field names. Configure a MailerSend template before depending on notifications; the stored PDF-notification option does not yet generate an attachment.

Test from the published origin #

  1. Publish only when the current site mode supports the form. The immutable release gate currently fails closed for form-containing pages.
  2. Open the public hostname, not the editor preview, and submit a distinctive test value.
  3. Confirm the success state is announced and keyboard focus ends somewhere sensible.
  4. Verify the submission in the dashboard and, when configured, the target table. Treat an email as secondary confirmation.
  5. Submit invalid data, a missing required field, and the form twice. Confirm errors are understandable and duplicate behavior is acceptable.
You will know it worked when a valid published submission appears once at the authoritative destination, invalid input is rejected accessibly, and no private response field is rendered by a public database binding.