# 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.

Available on the Grow, Scale, and Pro plans.

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.

![Opt-in form actions editor with the subscriber form preview](https://rightmessage.com/help/screens/forms-actions.light.webp)

## Send submissions to your email platform

Your [connected integration](https://rightmessage.com/help/how-integrations-work) 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](https://rightmessage.com/help/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](https://rightmessage.com/help/form-fields-reference) and [contact syncing](https://rightmessage.com/help/synchronizing-contact-data-with-your-email-platform-or-crm).

## 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](https://rightmessage.com/help/flow-node-offer-form).

## 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](https://rightmessage.com/help/publishing-your-changes) before visitors on your normal website can use them.