Form Builder

The Form Builder lets portal administrators create, publish, and manage custom web forms without writing code. Forms live at a public URL, can be embedded in Page Builder pages, and can forward submissions to your own backend, send email notifications, and store responses for review.

What it's for

• Contact / talk-to-sales — Collect name, email, and a message, then forward to a CRM webhook or notification inbox
• API access / early-access requests — Restrict the form to logged-in developers and route submissions to your backend
• Feedback / surveys — Use dropdowns, radio buttons, and long-text fields; store responses in the portal
• Onboarding / intake — Group fields in one- or two-column layouts with required-field validation
• Event / webinar signups — Publish a public form and email a notification on each submission

Creating a Form

From the Form Builder list, click New Form. Create and edit flows share the same four-step wizard.

Step 1 — Details

• Form Name — Required. Auto-generates the URL slug until you edit the slug yourself
• URL Slug — Required. Becomes the public path for this form. Nested slugs are allowed. The wizard shows the public URL as you type.
• Description — Optional rich text. Shown on the live form when it does not merely repeat the form name.
• Status — Draft, Active, or Archived

Step 2 — Fields

Add standalone fields or groups. Groups can have an optional label and lay out child fields in one or two columns. Fields can be reordered by drag-and-drop.

Each field has a label, type, optional placeholder, options (for select/radio), and a Required checkbox. At least one field must be marked required before you can save.

Step 3 — Email template

Optionally email an administrator and/or the person who submitted the form. Each mail has its own switch. Subject is plain text; body uses the same rich-text editor as other portal emails. Delivery uses the portal SMTP configuration — see Email Configuration.

Administrator notification

When on, every submission sends to the Administrator email you enter. A valid address is required while this switch is on.

Recipient confirmation

When on, choose Send confirmation to:

• A field from the Fields step — typically an Email field. If the form has no Email field, you can still pick another field that will contain an email address.
• User profile email — the signed-in account. Anonymous submitters do not receive this email.

You must pick a recipient or turn the switch off before continuing.

Tokens

Click a token to insert it into the last focused subject or body. System tokens:

Under Field values, each form field gets a chip — usually from its label (for example [work_email] for a field labeled Work email). If that name is already used by a system token, the chip uses a field: prefix instead.

If subject or body is left blank, Launchpad uses a default template. Email send failures are logged and never block a successful submission.

Step 4 — Configurations

• Submission message — Shown after a successful submit
• Form access — Public, or restricted to one or more allowed roles
• Limit submissions per user — Maximum times the same user can submit. Leave blank for unlimited. Signed-in users are counted by account; public submissions by email. Setting a limit also turns on Store submissions in this portal.
• Webhook URL — HTTPS endpoint that receives a POST with the submission payload
• Store submissions in this portal — Save responses for later review, search, and CSV export
• Webhook payload (JSON) — Customize the body sent to your webhook, with a reset-to-default option
• Signing secret — Generated automatically when a webhook is configured; shown (reveal/copy) on the form's Submissions page

Publishing

Set status to active and save. Visitors fill the form at the public URL shown on Details. You can also embed an active form in a Page Builder page with the Form block.

Webhooks

When a webhook is configured, Launchpad POSTs each submission to your endpoint. Delivery is durable: a failed attempt is recorded for retry and the submitter still sees success.

Default payload

{
  "formId": 1,
  "formSlug": "contact-sales",
  "formName": "Contact Sales",
  "submittedAt": "2026-07-09T12:00:00.000Z",
  "fields": [
    { "id": "f_123", "label": "Email", "type": "email", "value": "user@example.com" }
  ]
}

Custom payload templates can use tokens such as {{formId}}, {{formSlug}}, {{formName}}, {{submittedAt}}, and {{field:fieldId}}.

Signing

Every outbound delivery includes:

• X-Webhook-Timestamp — Unix seconds when the request was signed
• X-Webhook-Signature — sha256=<hex> HMAC-SHA256 of timestamp.rawBody

On your receiver, recompute the HMAC with the form's signing secret, compare it to the header, and reject timestamps outside your clock-skew window. Reveal or copy the secret from the form's Submissions page.

Reviewing submissions

Open Form Builder → [form] → Submissions (requires View Form Builder Submission) to:

• Search and paginate stored responses
• Export submissions as CSV
• Delete a submission (requires Edit Form) for GDPR/CCPA erasure
• Inspect webhook delivery status and retry failed deliveries
• Review the form's activity log

Access control

Who can build forms

These permissions are assigned to Admin/Administrator roles by default. See Role-Based Access for how to assign them to other roles.

Who can fill out a form

• Public forms accept anonymous submissions (subject to rate limiting, honeypot, and optional CAPTCHA)
• Role-restricted forms require the visitor to be logged in with a role listed on the form

Spam protection

• Rate limiting on the public submit endpoint
• Honeypot — a hidden field that silently drops bot submissions
• Body size cap — oversized payloads are rejected
• CAPTCHA — when enabled in Configuration → Captcha and this form is selected, Cloudflare Turnstile or reCAPTCHA is required