Limited Release

Forms are in limited release and are not generally available. Contact your account manager to request access.

Forms

A form is a public-facing web form that triggers automation when someone submits it. You define the input fields the visitor fills in, the actions the system runs after submission, and a success message to display when the run is accepted.

Use forms to collect structured input from people outside your account (customers, end users, teammates without console access) and feed that input directly into your automation workflows.

If the trigger is an inbound email, see Email Processing. If it is a schedule, see Scheduled Tasks. If it is a PSA event, see Workflows.

What a Form Contains

Each form has four parts:

Part	Purpose
Name and description	How the form appears in the console list, at the top of the public page, and in history.
Input fields	The named fields the visitor completes before submitting. Each field has a type, optional label and description, optional default value, optional query-string population, and optional conditional visibility rules.
Actions	The ordered list of action steps the system runs after a successful submission. Forms support the same action library as macros.
Success message	The message the public page displays after a submission is accepted. Defaults to "Your submission has been received."

Managing Forms

Click Apps in the top bar, then click Forms. From the Forms page you can:

• Create a new form with the New Form button.
• Edit a form by selecting its name in the list.
• Clone a form to start a new form from an existing one. Cloned forms start with public access disabled and no public URL.
• Test a form to run its actions end-to-end against sample inputs without going through the public page. Test submissions do not require the security check.
• Delete a form when it is no longer used. Deleting a form immediately stops its public URL from accepting submissions.

The list shows each form's name, description, action count, public-access status, and created date.

The Form Editor

Open a form to edit it. The top of the editor has three always-visible fields:

• Name: required. Shown on the public form page.
• Description: optional. Shown as help text at the top of the public form page.
• Success Message: optional. Shown to the visitor after a successful submission.

Below those fields, the editor has three tabs:

Input

Define the fields the visitor completes. Select Add Field to create a field, then configure it in the field editor. Use each field's row actions to edit, clone, or delete it.

Each field has:

• A name that the action list references as {{input.name}}.
• An optional label shown to visitors. If you leave the label blank, the form uses the field name.
• A type: text, textarea, password, number, integer, boolean, enum (single choice), list of text, list of enum values, or hidden.
• An optional description shown as help text on the public form.
• A required flag.
• An optional default value.
• An optional Allow Query Population setting.
• Optional Conditional Visibility rules.

Mark sensitive fields (tokens, one-time secrets) as password so their values are masked in the history log.

Text inputs accept up to 10,000 characters per field on public submission.

Field Types

Type	Use it for
Text	Short text values such as a name, subject, or reference number.
Textarea	Longer free-form responses such as descriptions or notes.
Password	Sensitive values that should appear masked in history.
Number	Decimal numeric values.
Integer	Whole-number values.
Boolean	A true or false choice.
Enum	A single choice from a fixed list of allowed values.
List of text	Multiple text values.
List of enum values	Multiple choices from a fixed list of allowed values.
Hidden	Values that should submit with the form but should not display to the visitor.

For enum fields, add at least one allowed value. The public form rejects submitted values that do not match the allowed list.

Default Values

Set Default Value when a field should have a fallback value if the visitor does not provide one. Defaults apply before the form validates the submission, so action steps can read the value from {{input.name}} just like a visitor-entered value.

For visible fields, a visitor-entered value takes priority over the default. For hidden fields, the public page never sends a visitor-entered value, so the default supplies the field unless query-string population replaces it.

Query-String Population

Enable Allow Query Population when a form link should prefill a field from the URL. The query parameter name must match the field name.

For example, if a field is named source, this URL submits webinar as the source value unless the visitor changes the visible field before submitting:

https://example.com/forms/abc123?source=webinar

Visible fields resolve values in this order:

1. Visitor-entered form value.
2. Query-string value, if Allow Query Population is enabled.
3. Default value.

Hidden fields resolve values in this order:

1. Query-string value, if Allow Query Population is enabled.
2. Default value.

If Allow Query Population is off, the form ignores matching query parameters for that field. A blank query parameter replaces the default with a blank value.

Hidden Fields

Use hidden fields to pass context into the form submission without asking the visitor to type it. Common examples include campaign codes, referral sources, embedded-page identifiers, or internal routing hints.

Hidden fields do not render on the public form and cannot use conditional visibility rules. They still validate against their configured type and become available to actions as {{input.name}} after submission.

Conditional Visibility

Use Conditional Visibility to show a field only when other visible field values match rules you define. For example, show an Additional Details field only when a visitor selects Other from a Request Type field.

Conditional visibility supports rule groups that match either:

• All conditions (AND): every rule in the group must match.
• Any condition (OR): at least one rule in the group must match.

Available operators depend on the field type you compare against:

Compared field type	Operators
Text, textarea, password, enum, list values	Equals, does not equal, contains, does not contain, begins with, does not begin with, ends with, does not end with, is empty, is not empty.
Number or integer	Equals, does not equal, greater than, greater than or equal to, less than, less than or equal to, is empty, is not empty.
Boolean	Equals, does not equal.

The form validates only fields that are visible when the visitor submits. If a hidden-by-condition field is marked required, the form does not require it until its visibility rules match. The form also ignores crafted submitted values for fields hidden by conditional visibility.

Actions

The ordered list of action steps the system runs when the form is submitted. Forms support every action that is available in macros, including PSA actions, HTTP requests, AI calls, and control structures. Actions that only make sense when processing email (for example, email-reply stop actions) are not available.

Reference the visitor's input as {{input.name}}. Store intermediate work in {{custom.name}}.

Forms are not callable from other automations, so there is no output namespace. All action results go into custom (the namespace toggle on each action is disabled).

Public

Controls whether the form accepts submissions from the internet.

• Enable public access: a checkbox that flips the form between private (test-only) and public (accepting submissions from anyone with the link).
• Public URL: the full shareable URL. Available after you save a form with public access enabled. A Copy button copies the URL to your clipboard.
• Embed Code: a ready-to-paste <iframe> snippet for hosting the form on your own website. A Copy button copies the snippet to your clipboard.
• Regenerate URL: creates a new public URL and invalidates the old one. Anyone using the old URL immediately loses access. Use this if the URL is leaked or shared with the wrong audience.

When public access is enabled but the form has not been saved yet, the Public tab shows "Save the form to generate a public URL."

Submitting a Form

The public page

Visitors open the form's public URL in a browser. The page renders the form's name, description, and each input field as a labeled control. Required fields display an inline validation message if left blank. A Cloudflare Turnstile security check appears above the submit button and must be completed before the submission is accepted.

After a successful submission, the page replaces the form with the configured success message.

What happens on submission

1. The system verifies the Cloudflare Turnstile token. If the check fails, the visitor is asked to try again.
2. The system validates each field against the form's input schema (required flags, data types, enum values, length caps).
3. A history record is created with trigger type form_submission and status set to in-progress.
4. The form's action list runs in order. Inputs are available as {{input.name}}; intermediate work is stored in {{custom.name}}.
5. The history record is marked complete or failed based on the result.
6. The public page displays the configured success message.

Rate limiting

Public form endpoints are rate-limited per IP address and path. Submissions beyond the limit receive a 429 response with a retry message. Legitimate visitors submitting once are never affected; the limit exists to block abusive automation.

Embedding a form

Copy the Embed Code snippet from the Public tab and paste it into any HTML page. The form renders inside an iframe and works the same way as the standalone public page.

Testing a Form

The form detail page and the list row action both open the shared test modal. The modal:

• Displays each input field defined in the form's Input tab.
• Lets you fill in sample values.
• Runs the form's actions end-to-end against a synthetic test trigger.
• Streams live execution logs so you can inspect every step as it runs.
• Records the run in History under a form_submission trigger with source test, so you can reopen the full history entry later.

The Cloudflare Turnstile check is skipped for tests; only public submissions require it.

Use the test modal to verify the form behaves correctly before you share the public URL.

Variable Behavior

Forms have three variable namespaces. See Variable Namespaces for the full reference.

• {{input.name}} is read-only and contains the visitor's submitted values.
• {{custom.name}} is the default place to store action results within the form.
• {{meta.history.id}} and {{meta.history.url}} reference the current processing run.

Forms do not have global or output namespaces. Each form run is isolated; nothing carries over between submissions.

Security

• Cloudflare Turnstile verifies every public submission before the action list runs.
• Per-IP rate limiting blocks submission floods from a single source.
• Partner-scoped URLs: each form's public key is unique and only resolves within your account.
• Password field masking: input fields marked as password type are redacted in history logs.
• URL regeneration: rotate the public URL at any time without rebuilding the form.

Only enable public access on forms you are ready to share. A form with public access disabled cannot be submitted through its URL.

Related Topics

• Macros: the reusable automation primitive that shares its action library with forms
• Variable Namespaces: how input, custom, and meta behave inside a form
• Expression Builder: build expressions that read form inputs