Form submission actions reference
You'll find what each form action sends, which destinations it needs, and how to check that your email platform or webhook received a submission.
Use this reference to choose where your form sends visitors' details. In Actions, the card What should happen when this form is submitted? has an Action selector. You choose one action type, rather than a sequence of different actions.
Send submissions to your email platform
Your connected integration determines which actions you can choose. Your connection also needs permission to write to the selected lists, forms, or contacts.
| If you'd like to… | Choose this action | Select these destinations |
|---|---|---|
| Send the submission to your platform's forms | Submit a form | One or more Forms. |
| Subscribe the visitor to lists | Add to a list | One or more Lists. |
| Apply tags to the contact | Add a tag | One or more Tags. |
| Record events in your platform | Trigger an event | One or more Events. |
| Enroll the visitor in automations | Start an automation | One or more Automations. |
| Save submitted fields to the contact profile | Create or update a contact | No destination IDs needed. |
Some platforms provide a list of destinations to select. Others accept comma-separated destination IDs. All five actions other than creating or updating a contact need at least one destination.
Event metadata appears when your platform supports it. Each value can use Liquid templates. Metadata applies to the event action, not every form action.
A missing integration or incomplete destination shows a warning that submissions can't be sent. Fix that warning before using the form, even if it looks right in the preview.
Send a webhook
Send a webhook sends submissions to your own HTTPS endpoint without an email-platform integration. Sending form webhooks requires Pro. If your plan doesn't include it, the editor shows the plan requirement.
| Setting | What you can enter |
|---|---|
| Where to send it | A valid HTTPS URL with a hostname. An empty or malformed URL leaves setup incomplete. A nonempty invalid URL shows an inline error. |
| HTTP method | POST, PUT, or PATCH. A new webhook starts with POST. |
| Extra data | Optional JSON, sent as meta in the request. The editor shows JSON parsing errors. |
| Payload preview | An expandable example with sample values, not a recorded delivery. |
Available template values include visitor.email, visitor.id, flow.id, flow.node_id, page.url, segments.KEY, and variables.KEY.
The email address is in form.email. Other submitted values are in form.fields, with keys based on the field labels visitors see. Renaming or personalizing a label can change a key your receiver expects. Layout blocks don't become submitted values.
Requests include an X-RightMessage-Signature header signed with HMAC-SHA256. The editor links to the project settings where you'll find the webhook secret. Your receiving server should verify that signature. The webhook reference covers payloads, signatures, delivery, and limits.
A form webhook fires for each submission. It doesn't use the once-per-visitor behavior of a default Webhook flow node. RightMessage queues it through the relay. A submission event or conversion count means it was queued, not that your receiver accepted it.
Choose where each answer is saved
The action decides what to do with a submission. Field mappings decide where individual answers go. For example, applying a tag doesn't also map every question to a custom field.
Linked questions submit with the form, not as separate question interactions. A question without a sync mapping can collect an answer without saving it to a field in your platform. See the form fields reference and contact syncing.
What happens after submission
RightMessage validates fields before submitting. While a submission is in progress, double-clicking the button won't submit it again. If your email platform rejects the operation, the form can show an error and let the visitor retry.
After your platform accepts the operation, RightMessage records submission activity and follows the form's post-submit path. For a webhook, it records submission activity when the request is queued.
The form ends the ordinary path through its parent flow. Its dedicated post-submit path decides what happens next, such as a confirmation or redirect. It doesn't continue through ordinary nodes placed after the form. See the Offer and Form node reference.
Check that the submission arrived
The form preview doesn't send a live contact update, and the authorized debugger simulates actions. To check delivery, submit on your normal website using a test identity you control. Then inspect the contact in your email platform or the delivery at your webhook receiver.
If the form appears to succeed but a value is missing, check the destination IDs, permissions, field compatibility, and mappings. Allow for any delayed processing. Changing the widget's design won't fix a failed request to your platform.
You can't edit Fields or Actions while the form has a draft or running A/B test. A completed test doesn't keep those tabs locked. Publish your draft changes before visitors on your normal website can use them.