Form Block


Documentation contact example

A compact contact form with clear labels, consent, and a useful success state.
Name
Email
Message

Use Form to collect a focused set of responses with clear labels, predictable validation, an explicit consent choice, and a useful success state. The live block above is the same standard Luna form documented below.


Properties

Form Properties panel with fields, button, consent, and submission settings in a clear retina documentation capture

Properties controls the form identity, ordered fields, visual rows, button, consent, delivery, and post-submission feedback. Build and test the data contract before styling.


Form identity and description

Form Name identifies the form in submissions and should be specific enough to distinguish it from other forms. Description is optional rich text shown above the fields; use it to set expectations, not to repeat every label.


Fields and layout rows

Every field needs a stable unique ID, a unique submission name, a supported type, and a visible label. layoutRows is the canonical visual layout: reference every field exactly once and use only the supported 12-column spans. Field order should match the intended keyboard and reading order.


Field types

Form supports text, email, telephone, textarea, checkbox, radio, select, number, date, date range, time, range, URL, file, hidden, address, name, divider, currency, survey, and display fields. Configure type-specific options such as choices, date limits, time step, file acceptance, and textarea rows only when they are relevant.


Button

Button Text should describe the action. Button Alignment positions the control, and Full Width Button expands it across the form. Keep the label concise and preserve a minimum touch target in the rendered View.


Consent

Show Consent adds the checkbox and privacy link. Configure the text before the link, link label, destination, and whether consent is required. Use a real privacy-policy URL and do not preselect an agreement.


After submission

Success Message replaces the form after a successful submission. Notification Email controls the internal recipient; leaving it empty uses the site admin. Confirmation emails require the site’s own Mail sender and SMTP settings, and their subject and body can reference submitted field names such as {name} or {email}.


Connect SMTP before sending confirmation emails


Send Confirmation Email works only after the site owner configures Email / SMTP. In Dashboard, open the site’s Settings and complete the SMTP configuration, then return to Form Properties and enable the confirmation email. See SMTP & Email Delivery for the complete setup.

Site Settings Email and SMTP panel on the newsitetest site, highlighted without browser chrome


Container and input controls

Container Style, Surface Color, Input Style, Input Size, Label Style, Corner Radius, Padding, Field Gap, and Shadow establish the baseline before Style Panel overrides. Choose a visible surface and keep labels, fields, focus, and validation states readable against it.


Layout

Form uses a 12-column internal row system and a content-driven section frame. Keep related fields on the same row only when their labels and inputs remain usable; stack fields on narrower widths before reducing text or touch targets.


Behavior

Required fields participate in native and Luna validation. Submission uses the configured payload names, displays the Success Message when accepted, and can trigger internal and confirmation email workflows. Test validation, consent, error, success, and duplicate-submit behavior without relying on placeholder text.


Style Panel

Style Panel areas include Body, Label, Button, Text Input, Textarea, Select, Checkbox, Radio, Survey, Range, File Upload, and Privacy Policy. Style the stable default state first, then add a clear Button hover state and preserve visible keyboard focus.

Form Style Panel with area and responsive styling controls in a clear retina documentation capture

Body controls the bounded form surface; each field-area target controls its matching input type. Keep consistent borders, padding, font size, and contrast across field types so the form reads as one system.


Motion

Form supports standard entrance effects, while Button hover feedback belongs in the Style Panel. Avoid repeated or large entrance motion on a task-focused form, and verify reduced-motion behavior before enabling any effect.


Property summary

Fields and layoutRows — submission data contract and 12-column visual order.

Container Style and Surface Color — form surface treatment.

Input Style, Input Size, and Label Style — shared field presentation.

Corner Radius, Padding, Field Gap, and Shadow — container geometry.

Button Text, Alignment, and Full Width — primary action.

Consent settings — checkbox copy, privacy link, and required state.

Success Message and notification settings — post-submission feedback and delivery.

Confirmation email settings — optional sender-dependent reply to the submitter.


Responsive behavior

Form is content-driven and starts from a 16-column by 10-row grid frame. Its rendered height follows field count, textarea rows, consent, button size, padding, and wrapping.

On tablet and mobile, verify every label and message, stack internal rows when needed, keep fields inside the surface, preserve touch targets, and shrink only unused grid rows after the complete form remains visible.


Accessibility

• Give every visible control a persistent label; placeholders are supplementary hints, not replacements.

• Keep DOM, keyboard, and visual order aligned with layoutRows.

• Associate errors with their fields and make the error summary understandable without color alone.

• Preserve visible focus and comfortable touch targets for inputs, consent, links, and the submit button.

• Announce success and failure clearly, and move focus deliberately when the form is replaced by the Success Message.


Best practices

• Ask only for information needed for the stated purpose.

• Use stable field names before configuring notifications or email templates.

• Link to the real privacy policy and explain how the response will be used.

• Test required, invalid, long, mobile, success, and delivery states.


Common mistakes

• Using placeholders as the only labels.

• Leaving a field out of layoutRows or referencing one field more than once.

• Enabling confirmation email without configuring the site Mail sender and SMTP settings.

• Keeping a generic Success Message that gives no next step.

• Saving an oversized grid frame after fields have been removed.


Quick recipe

Name the form, define each field and submission key, mirror every field once in layoutRows, configure the button and consent, write the success state, verify notification delivery, style the default and focus states, then test the complete flow at desktop, tablet, and mobile widths.

Questions, ideas, or bugs?

Explore what we’re building next, ask the Luna team for help, or send a focused bug report.