Forms

Public Forms collect data from external users through a hosted web form. Every submission triggers any workflows you've wired to that form, with the form data exposed as {{trigger.data.fields.<name>}}.

Forms are organization-level resources (like AI Providers and MCP Servers). You create them once in Settings → Forms and assign them to specific workspaces.

Creating a Form

1. Go to Settings → Forms.
2. Click Create Form - gives you an empty form with no fields.
3. Add fields - pick from text, email, number, textarea, select, file upload, or checkbox. Each field has:
   • Label - what the user sees.
   • Name - the JSON key in the workflow payload ({{trigger.data.fields.<name>}}). Stable across edits.
   • Required / validation rules - min/max length, regex, file size, accepted file types.
   • Placeholder + help text - both optional.
4. Choose a layout - Stack (vertical) or Grid (2-column). See below for tradeoffs.
5. Configure branding - logo, colors, backgrounds. See Branding.
6. Click Save to keep editing as a draft, or Publish to make it live.

Drafts have status DRAFT and are not reachable at the public URL. Published forms have status PUBLISHED.

Layouts

The layout controls how fields stack on the page. Pick Grid when you have many short, related fields (name + email, city + zip, etc.) and Stack when fields need their full breathing room (long textareas, file uploads).

In Grid layout, set each field's width to full or half from its inspector. Half-width fields pair up automatically left-to-right; a full-width field always starts on its own row. On mobile, grid collapses to a single column regardless of field width.

The visual layout builder shows the field arrangement as you drag - you don't have to publish-and-check to see the result.

Branding

Branding is configured per form (no org-wide theme). Every option is optional - leave a field blank and the form falls back to a neutral default.

Logos and background images are stored in the organization's file bucket. They are served from a presigned URL - there is no separate CDN configuration to do.

Public URL

Published forms are reachable at:

/f/<publicToken>

publicToken is a 192-bit random base64url string. Anyone with the URL can submit; there is no authentication on the form side.

If closeAfterDate is set, the form returns a "closed" message after that date instead of the form. If maxSubmissions is set, the form returns a "submissions closed" message once the count is reached.

A built-in honeypot field guards against naive bots; it can be disabled per-form (enableHoneypot: false) if you ever need to reach the form from an automated tool you control.

Embed Mode

Add ?embed=1 to the form URL to render it for iframe embedding on an external site:

<iframe
  src="https://your-domain.com/f/TOKEN?embed=1"
  width="100%"
  height="600"
  frameborder="0">
</iframe>

Embed mode strips:

• The page background (image and color)
• The logo and the form card chrome
• The default page padding

…leaving just the fields and the submit button. Use the form's Form background color to control how it looks against your host page's background.

Wiring a Form into a Workflow

A form by itself just collects data. To turn it into a trigger, you connect it to one or more workflows.

Step 1 - Assign the form to a workspace

Forms are organization-level. Workspaces have to opt in:

1. Settings → Workspaces → Edit the workspace.
2. Under Forms, check the form you just created.
3. Save.

Only forms assigned to the current workspace are pickable from the workflow editor.

Step 2 - Use triggerType: "form" in the workflow

1. In the workflow editor, click the Trigger node.
2. Set Trigger type to Form.
3. Pick the form from the dropdown - only workspace-assigned forms appear.
4. Save the workflow and activate it (status ACTIVE).

When a user submits the form, every active workflow with a matching formId is triggered. Triggering is fire-and-forget: the form's success message renders as soon as the submission is queued, not when the workflows finish.

Step 3 - Read submission data in the workflow

The trigger payload follows a standard shape:

{
  "formId":    "form-cuid",
  "formName":  "Lead intake",
  "submittedAt": "2026-04-30T12:00:00.000Z",
  "fields": {
    "name":  "Ada Lovelace",
    "email": "ada@example.com",
    "company": "Analytical Engines Ltd"
  }
}

Reference these fields in downstream nodes via:

• {{trigger.data.fields.<name>}} - values for non-file fields
• {{trigger.data.formId}} / {{trigger.data.formName}} / {{trigger.data.submittedAt}} - submission metadata

File fields

File uploads are stored in S3 and surfaced as objects:

{
  "fields": {
    "resume": {
      "fieldName": "resume",
      "s3Key":     "forms/<form-id>/<submission-id>/resume.pdf",
      "url":       "<presigned-download-url>",
      "name":      "ada-lovelace-resume.pdf",
      "size":      245678,
      "contentType": "application/pdf"
    }
  }
}

Pass {{trigger.data.fields.resume.url}} to a downstream HTTP node to download, or reference s3Key to operate on the file via the Files (S3) MCP server.

Submissions

View the raw submission history in Settings → Forms → (form) → Submissions. Each entry shows the timestamp, the field values, and links to any uploaded files. Submissions are kept independently of execution history - even if a triggered workflow fails or is deleted, the submission record stays.

Plan limits

The number of forms you can have per organization is governed by your plan. See Plans & Limits for current numbers.

Related

• Triggers - full Trigger node reference, including form
• Workspaces - where the form-to-workspace assignment lives
• Variables & Templates - how {{trigger.data}} references work in nodes