---
title: "What Happens After Submit"
description: "How to set up the email notifications, thank-you page, and redirects that run once a respondent submits, including how to insert their answers into that content."
slug: "after-the-submit"
audience: "all"
generated_at: "2026-10-16T21:22:43.263Z"
screenshots:
  - "/docs/screenshots/after-the-submit/builder.png"
---

After a respondent clicks **Submit** on a FormAssembly form, the workflow keeps running. The Collect step hands the submitted answers to whatever steps you placed after it — a confirmation message, an email, a redirect, or a connector that sends the data to another system. This article explains each of the post-submit steps, how to configure them in the FormAssembly builder, and what respondents and workflow owners see when something goes wrong.

![The FormAssembly workflow builder showing a Collect step followed by a Respond step](/docs/screenshots/after-the-submit/builder.png)

## What happens the moment a respondent clicks Submit

FormAssembly saves the submitted answers, then moves the run forward through the steps you added after the Collect step, in order:

- **Respond** steps show the respondent a confirmation (thank-you) message and end their visible journey.
- **Email** steps send a templated email — to the respondent, to your team, or both — without the respondent waiting on a browser screen.
- **Redirect** steps send the respondent to an external web address.
- **Connect** steps push the data to a connected service.

A workflow can also generate a document, collect an e-signature, ask for an approval, or hand work to someone else through an assignment after the Collect step; see also: Building Workflows for those step types.

Steps that do not require the respondent's presence (such as Email and Connect) run immediately and pass the run along, so the respondent is not left waiting. Every submission is recorded and viewable from **Responses** in the workflow's top navigation, alongside **Analytics** for aggregate reporting and **Execution log** for a list of what has failed.

To add a step after Submit, switch to **Focus** view in the builder and click **Add step**, then choose the step type you want. Adding, duplicating, moving and deleting steps are all Focus-view actions. **Overview** is a read-only map of the whole workflow: it draws every step and the connections between them, and clicking a step card there switches you to Focus. You can also ask **Fai**, the FormAssembly AI assistant in the side panel, to add a step from either view — only the **Add step** button is Focus-only. The **Add step** menu's **Connect** group contains one item, **Salesforce**; every other connector's step is added by asking Fai.

## The Respond step: your confirmation page

A **Respond** step is the thank-you or confirmation screen shown to respondents after they submit. A new workflow starts with a Respond step named **Thank You**, and its confirmation message defaults to "Thank you." A Respond step you add yourself from the **Add step** menu is named **Thank you** and starts with an empty message — fill in a confirmation message before you publish, because publishing requires one.

The Respond step is the last thing most respondents see, so it is worth more than a bare acknowledgement — use it to tell people what happens next, how long a review takes, or where to check for a follow-up email.

### How do I edit the confirmation message?

1. Click the Respond step on the canvas to open its editor.
2. Edit **Step name** if you want a clearer label on the canvas (for example, "Under Review"). The same value appears as **Step Name** on the step's settings.
3. Type your message in the **Confirmation message** editor.
4. Use the formatting toolbar for **Heading 2**, **Bold**, **Italic**, **Underline**, **Bullet list**, and **Ordered list**.

Edits are saved as you go. Hyperlinks are intentionally not available in the confirmation message editor.

### Confirmation message templates

The first time you open a Respond step, a dismissible template banner appears at the top of the editor with four presets plus a **Describe other** option:

- **Confirmation** — "Thank you! Your submission has been received…"
- **Next Steps** — "You're not quite done yet. Check your inbox for instructions…"
- **Registered** — "You're all set! Your spot is confirmed…"
- **Under Review** — "We've received your information. Your submission is under review…"

Click a preset to fill the **Confirmation message** editor with that copy, then edit it freely. The presets are deliberately generic and contain no Field References, so personalizing is your next step — after you apply a template, focus moves to **Insert field value** so you can add a Field Reference right away.

Click **Describe other** to hand off to **Fai**, the AI assistant in the side panel, and describe the confirmation message you want in your own words. **Describe other** does not change your message on its own; Fai writes the message for you.

Click the ✕ on the banner to dismiss it. The banner stays hidden for that Respond step for the rest of your builder session, but it is not remembered after a page reload.

### Personalizing with Insert field value

Use **Insert field value**, located below the **Confirmation message** editor, to drop an answer from an earlier Collect step into your message — for example, "Thanks, Alex — we've sent a copy to alex@example.com." A `{{ … }}` value placed in text is called a **Field Reference**, and **Insert field value** is the builder picker that adds one.

1. Place your cursor where the value should appear.
2. Click **Insert field value**.
3. Search or scroll the list of fields from preceding Collect steps and choose one.

The inserted reference appears as a labeled chip (for example, "First Name") rather than the raw `{{ … }}` reference. At submission time, FormAssembly replaces the chip with the respondent's actual answer. If a field is missing or has no value, the reference resolves to empty text rather than showing an error.

**Insert field value** is disabled — with an inline explanation — when there is no preceding Collect step with fields, since there would be nothing to insert.

Field References are not limited to post-submit steps: a text block on the form itself can show one too, which is useful for displaying a value collected earlier in the workflow. See also: Designing Forms.

## Sending an email after submit

An **Email** step sends a templated email when the respondent reaches that point in the workflow. Add an Email step after your Collect step to send a receipt to the respondent, notify a colleague, or both.

Click the Email step to open its editor and fill in the fields you need. All fields are optional in the editor, but a workflow needs **To**, **Subject**, and **Message** filled in to send successfully.

| Field | What it does |
| --- | --- |
| **Step name** | The label shown on the step's card in the builder. |
| **To** | The recipient address. Separate multiple addresses with commas. |
| **BCC** | Blind-copy addresses. Separate multiple addresses with commas. |
| **From name** | The display name recipients see. |
| **Reply-to** | The address that receives replies. |
| **Reply-to name** | An informational name shown alongside the reply-to address. |
| **Subject** | The subject line. |
| **Message** | The email content, edited as rich text (bold, italic, underline, lists, links). |
| **Attachments** | Files from the workflow to attach to the email. |

Text fields are saved when you click out of them, so click elsewhere after typing to commit a change. Clearing a field and clicking out clears the stored value.

There is no **Cc** field in an Email step. Use **To** for visible recipients and **BCC** for recipients who must not see each other.

### Which address does the email come from?

Workflow emails are always sent from the FormAssembly platform sending address. An Email step has no **From email** field, because sending from your own domain requires sender-domain verification, which FormAssembly does not offer yet. Use **Reply-to** to control where replies land.

**From name** overrides only the display name portion: if you set it, recipients see your name next to the platform sending address. If you leave **From name** blank, the sending address is shown as-is.

### Personalizing emails

Every text field in an Email step — **To**, **BCC**, **Reply-to**, **Subject**, and **Message** — supports Field References written as `{{ step_1.fieldId }}`, using the step and field identifiers from a preceding Collect step. The Email step does not yet have the **Insert field value** picker that Respond and Redirect steps have, so type the reference by hand, exactly in that form. FormAssembly resolves these references at send time, not while you are editing. That means you can email the respondent by putting a Field Reference for their email address in **To**, and greet them by name in the **Message**.

In **To**, each comma-separated entry must be either a complete email address or a whole Field Reference on its own. A reference spliced into an address, such as `{{ step_1.name }}@example.com`, is rejected when you publish. Separate multiple addresses with commas, never semicolons — a resolved recipient list that uses semicolons fails the step instead of sending to each address.

When **To** or **BCC** references a respondent's own answer — a text or email question, a field inside a repeating section, a choice whose labels are email addresses, or a value an assign step copies from one of those — that answer must resolve to at most one plain address, with no display name and no angle brackets. The limit applies to each referenced answer on its own; addresses you type yourself are not limited, so comma-separated literal addresses still work normally. An answer that carries two addresses (a text question in which someone typed `a@x.com, b@y.com`, or repeating-section rows holding different addresses) passes the form and then fails the step, and the **Execution log** reports it as **Email field invalid**. **Reply-to** follows the same rule: it must resolve to exactly one plain address.

Field References are also how you repeat a set of answers. A repeated block written as `{% begin step_1.sectionId %} … {% end step_1.sectionId %}` renders its contents once per submitted instance of that repeating section — useful for listing line items or multiple contacts in a single email.

An Email step sends one email addressed to the whole resolved recipient list; it does not send a separate email per person or per repeated instance. If recipients must not see each other, put the addresses in **BCC**. Duplicate addresses in a resolved list collapse to a single copy, and blank entries are dropped.

If **To** resolves to nothing on a live run — for example, the reference points to an optional email field the respondent left blank — FormAssembly sends the email to the workflow owner's address instead of failing the step, with one exception: an email that carries the respondent's resume link (the link that lets them return to a saved submission) never falls back to the owner, and the step fails instead, so the respondent's link is never mailed to someone else. The owner fallback keeps internal alerts from disappearing silently, but it also means a respondent receipt driven by an empty field lands in the owner's inbox. A **BCC** that resolves to nothing is simply omitted. A **Subject** built only from a Field Reference that resolves to empty text is sent with an empty subject line — it does not fail the step, so put some literal wording in **Subject** alongside any reference.

### Attaching files to an email

An Email step can attach files that already exist in the workflow. Click **Add a file** under **Attachments** in the Email step's editor and pick a file value from the list. You can attach:

- A file a respondent uploaded through a file upload field in a preceding Collect step.
- A file variable in the step's scope.
- The PDF produced by a Document generation step, or the document from an e-signature step. A signed document is attached as its current version.

Each attachment shows the step it comes from, and a file field inside a repeating section attaches every row's file. A file that is already attached is not offered again, and an attachment whose file no longer exists in the workflow stays listed, marked as missing, until you remove it.

The whole email, attachments included, must stay under about 10 MB. A larger email is not sent: the step fails with **Email too large** and follows its failure route. No file is ever dropped to make the email fit, so remove or shrink an attachment yourself if you hit the limit. A test run attaches the same files as a live run.

FormAssembly does not attach a PDF copy of the submission itself — only the file values listed above.

### What happens if the recipient address resolves to nothing?

On a published workflow, if everything in **To** resolves to nothing at send time — for example, the **To** field is a reference to an optional email question the respondent left blank — FormAssembly sends the email to the workflow owner's address instead of failing the step. The email still counts as a successful delivery in **Responses**, and the respondent is not sent down the failure route. The exception is an email that carries the respondent's resume link: that step fails rather than falling back to the owner, so a fresh resume link is never mailed to the owner in place of the respondent.

Two things follow from this behaviour, and both are worth planning for:

- An internal alert whose recipient is looked up during the run still reaches you, rather than disappearing, which is the point of the fallback.
- A respondent receipt addressed from an optional email question lands in the workflow owner's inbox when that question is blank. If you do not want that, make the email field required in the Collect step.

The fallback applies to live runs only, and only when **To** resolves to nothing. A **To** that resolves to an invalid address fails the step instead. In a test run, the recipient is always the person running the test anyway (see below).

## Redirecting respondents to another page

A **Redirect** step sends respondents to an external web address instead of showing a confirmation message. Use a Redirect step when the next step lives on your own website — a scheduling page, a payment page, or a knowledge base article.

1. Add a Redirect step after your Collect step.
2. Enter the destination in **Send respondents to**.
3. Optionally click **Insert field value** below the field to append an answer to the address — for example, adding an email address or record ID as a query value.

The address must start with `http` or `https`, can be up to 2,000 characters (a live counter shows how much you have used), and is required before you can publish. You can leave it empty while drafting, but the panel shows a required-field message until you enter a valid address. If a field holds a complete web address on its own, you can use a single Field Reference as the entire value.

Confirmation messages stay on the Respond step — a Redirect step does not display a message before sending the respondent away.

## How do I test what happens after Submit?

Click **Test** in the top navigation to run the workflow yourself before publishing. Test runs are deliberately isolated so real emails never reach real respondents:

- The recipient is replaced with the tester's email address — the signed-in user running the test — regardless of what **To** contains.
- **BCC** is suppressed entirely.
- The subject line is prefixed with `[TEST]`.
- A warning banner is added to the top of the email body, identifying it as a test send and showing the recipient the email would have gone to in production.

Test runs also never trigger owner failure notifications, and the live-run owner fallback does not apply to them: on a test run, an empty **To** fails the step so you find out before publishing. Address rules are still checked on a test run, so an invalid recipient fails the test send exactly as it would on a live run. Once the confirmation message, emails, and redirects look right, click **Publish**, then **Share** to distribute the form.

## What happens when a step fails?

If an Email, Connect or Document generation step cannot complete — an expired credential, an unreachable service, or a mail host that stops responding — FormAssembly handles the failure in three places:

- **The respondent** sees a short, friendly message on the next screen. Respondents never see raw error text, and they are never asked to resubmit.
- **The workflow owner** gets a durable record: the attempt is stored as a failed delivery with the underlying error, so you can see exactly what went wrong. **Execution log** in the workflow's top navigation lists these failures.
- **The workflow** follows the failure route you configured. Every Email and Connect step must have a failure route before you can publish, and that route can point to any other step — for example, a Respond step that tells the respondent their submission was received but is being processed manually. A failure route on a Document generation step is optional.

Failure emails to the owner are a workflow setting, and they are **off by default**: unless an individual failure route overrides the setting, a workflow that has not turned them on notifies no one. Turn on **Email the owner when a step fails** under **Properties → Notifications** to receive them. Fai or the API can also override the setting for a single failure route, and the route's own setting wins either way: a route set to notify the owner sends the email even when the workflow switch is off, and a route set to off sends nothing even when the workflow switch is on.

When notification is on, you receive an email with the subject `Action required: step failure in "{workflow name}"`. That email names the workflow and step, gives a human-readable reason (such as credentials expired, permission missing, rate limit exceeded, service temporarily unavailable, the connection selected for this step can't be used with its connector, the redirect step could not produce a valid link, or an invalid email address field), and includes how many failures have occurred since the last notification.

Failure notifications are debounced per workflow: after the first email, further notifications are suppressed for one hour while the failure count keeps accumulating. The next notification after that hour reports the full cumulative count. If failures stop entirely during a suppression window, no catch-up email is sent — check **Responses** for the failed deliveries to see the full picture. Notifications are not sent for test runs, or when there is no owner email available.

There is no automatic retry. When a step fails, investigate the cause, then replay the affected response: open it from **Responses** and replay it from the step that failed, either on the workflow as it stands or onto a corrected version of the workflow. See also: Viewing Responses, which covers replay in detail.

## Tips & Troubleshooting

- **The confirmation message shows a blank space where a name should be.** The referenced field had no value for that submission. Field References that resolve to nothing render as empty text by design. Make the field required in the Collect step if the value must always be present.
- **Always use Insert field value rather than typing a reference by hand.** Typing a full Field Reference directly into the Respond or Redirect editor can leave stray literal text around the inserted chip. **Insert field value** is the supported insertion path on those two surfaces.
- **A Field Reference is not resolving.** References must be written `{{ step_1.fieldId }}`, fully qualified with the step. The older double-percent spelling no longer resolves — it renders as literal text instead of the value.
- **A chip still shows an old field label after you renamed the field.** The label refreshes on your next edit anywhere in the confirmation message. Type a character and the chip updates; the stored reference was never wrong.
- **A chip is marked as unknown.** The reference points to a field that no longer exists — usually a deleted Collect field or a deleted Collect step. Delete the chip and insert a current field.
- **No email arrived.** Confirm the Email step has a value in **To**, **Subject**, and **Message**, and check that any Field Reference in **To** points to a field the respondent actually filled in. If the resolved **To** was empty, look in the workflow owner's inbox — a live run sends the email there rather than failing, unless the email carries the respondent's resume link, in which case the step fails instead and the failure appears in **Execution log**.
- **The Execution log shows Email field invalid.** A resolved address was not a single plain mailbox. The most common cause is a **To** or **BCC** reference to a respondent's answer that contained more than one address, or an address typed with a display name or angle brackets. Reference one email question that accepts a single address, and put additional recipients in the step as literal addresses.
- **The Execution log shows Email too large.** The message plus its attachments exceeded about 10 MB, so nothing was sent and the step followed its failure route. Remove an attachment, or attach a smaller file — FormAssembly never drops a file to make the email fit.
- **An attachment is marked as missing.** The file it pointed to is no longer part of the workflow, usually because the field or step that produced it was deleted. Remove the attachment and add a current file.
- **No failure email arrived.** Failure notifications are off by default. Turn on **Email the owner when a step fails** under **Properties → Notifications**. If that switch is already on, check the failure route's own notification setting as well — a route set to off suppresses the email even when the workflow switch is on. The failures themselves are always listed in **Execution log**.
- **You want the email to come from your own domain.** That is not available yet. Workflow emails always send from the FormAssembly platform sending address; use **Reply-to** to route replies to your own inbox.
- **You want to control the sender name only.** Set **From name** to change the display name recipients see.
- **Test emails went to you instead of the recipient.** That is expected. Test runs redirect all mail to the tester's address, prefix the subject with `[TEST]`, and suppress **BCC**.
- **You need multiple recipients.** Enter comma-separated addresses in **To** or **BCC**; semicolons are not accepted. A reference to a respondent's answer counts as a single recipient, so add any further recipients as literal addresses alongside it.
- **The confirmation template banner came back after a reload.** Banner dismissal lasts for the current builder session only and is not saved with the workflow.
- **You cannot publish because of the redirect step.** **Send respondents to** is required for publish and must be an `http` or `https` address (or a single Field Reference holding a complete address).
- **You cannot publish because a Respond step has no message.** A Respond step added from the **Add step** menu starts empty; type a confirmation message before publishing.
- **You cannot find Add step.** The **Add step** button appears in **Focus** view. **Overview** is a read-only map and does not add, move or delete steps.