Forms
Forms collect information from visitors and store submissions in your site. Manage them under Chatbot → Forms: map answers to Contacts, send copies to destinations such as email or Slack, and choose whether a form is shown in a widget or started by the assistant during chat.
Add form
Open Chatbot → Forms and click Add form. In the form editor, set the title and form type, then add fields, map columns, destinations, and visibility in the sections below.
Form types
Widget Forms
These render in the Form widget (for example on the Home tab or inside the chat shell). Choose Widget as the form type so the form appears in the widget picker (see the Widgets doc). AI Instructions are not used.
Conversational Forms
These are not added as a widget. The assistant offers the form when your AI Instructions match the conversation.
AI Instructions
In the form editor, describe when the assistant should run the form—for example, after a topic is resolved or when the user signals they are done. Example: Whenever the user’s issue is handled and they are satisfied, start collecting feedback.
Disable conversational forms
On Chatbot → Forms, find the form in the table and switch the toggle in that row.
Form fields
Add field
In the form add or edit screen, click Add field to open the field picker and insert a new field.
Add fields in the form builder. Available types by plan:
- Free: Text, Email, Phone, Textarea, Radio, Checkbox, Dropdown, Choices, Number
- PRO: Attachment, Date Calendar, plus all Free types
Map to contact columns
Map each form field to a column on Contacts: either an existing column or a new one created when none matches yet. Submitted values are stored as metadata on the contact created for that submission. New columns and mapping changes do not rewrite or backfill contacts saved earlier; those rows keep the data they held when they were stored.
Destinations
Submissions are stored in your WordPress database by default. You can also forward them to external destinations, depending on plan:
- Free: Email or Slack — one destination at a time
- PRO: Custom webhook, and several destinations at once (for example, email and webhook together)
Add destination
In the form add or edit screen, click Add destination to choose Email, Slack, a custom webhook, or another option your plan supports.
An Email destination sends a message each time the form is submitted—use it to alert your team, route leads to an inbox, or make replies easy by setting Reply-To to a submitted address (for example {email}). Configure To, Subject, Body, and optional Reply-To; combine static text with variables as needed (see the Variables section below).
Slack
A Slack destination posts each form submission to a channel using Slack’s Incoming Webhook. Add it from Add destination in the form editor, then fill in the three settings below.
- Title — The notification title shown at the top of the Slack message (bold in Slack).
- Body — The main message text sent to the channel. You can use Slack mrkdwn and the same kind of placeholders as in email to insert submitted field values.
- Webhook URL — The Incoming Webhook URL that connects this destination to your Slack channel.
Webhook URL: In Slack (your app at api.slack.com), enable Incoming Webhooks, add a webhook to the workspace, choose the channel—Slack gives you a URL; paste it here. Full steps: Getting Slack API Keys.
Custom webhook (PRO)
A Custom webhook sends an HTTP request to your URL when the form is submitted—useful for automation, your own API, or a CRM. Available on PRO; when your plan allows multiple destinations, you can run it together with Email, Slack, or other webhooks.
Configure these fields. All of them support Variables in the editor (see below).
- HTTP Method — The verb for the request (GET, POST, and other supported methods).
- Webhook URL — The endpoint to call.
- Query parameters — Optional, when you need a query string on the URL.
- Headers (JSON) — Request headers as a JSON object (textarea).
- Request body (JSON) — JSON body for methods that send a payload (not used for GET).
Set everything correctly for your endpoint, use realistic or dummy values in the request body (and in other fields as needed), then click Test Webhook. That sends a test request from the editor so you can verify the call before live submissions.
After you run a test, the response JSON is parsed up to two levels deep (top-level keys and one nested object level). Variables are generated from that structure and appear in the Variables picker for destinations that run after this webhook—so you can use returned data in a later Email or Slack destination, or chain another callback (see Variables below).
Variables
Destination fields (for example email To or Body, Slack Title or Body, and webhook URLs or payloads on PRO) can include variables: tokens that are replaced with data from the submission when the destination runs.
Use the Variables control next to a field to open the list and insert a token. Each form field appears as {field_name}—the same internal name you set for that field in the form builder (for example {email} or {full_name}). Add or rename fields and the list updates automatically.
On PRO, if you add more than one Custom webhook, destinations that run after an earlier webhook may also show extra tokens from that webhook’s response (when paths are defined from a test response), so later steps can use values returned by the first call.
Required destinations
Each destination has a Required setting. When it is enabled, that step must succeed for the submission to be treated as successful overall. If that destination fails, the system stops and does not run any later destinations in the list. The visitor sees a warning, but the submitted data is still saved to Form entries.
If you do not need a strict chain—or it is acceptable for a later destination to be skipped when an earlier one fails—leave Required off for the steps where a failure should not block the rest. Note: Custom webhook (HTTP) errors always stop later destinations as well, because those steps may rely on values from the webhook response.
Visibility
Conversational forms include visibility rules, similar to widgets: limit them by audience—Visitors, Contacts, or specific WordPress roles—so the assistant runs the form only for users who match.
Widget forms use the Form widget’s visibility. Configure that on Chatbot → Widgets.