> For the complete documentation index, see [llms.txt](https://docs.dapta.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dapta.ai/dforms/connect/emails.md). # Submission emails The two emails a form sends when someone completes it: the new submission notice and the respondent confirmation. Choose who receives the notice, follow the account template or write custom copy for o Every completed submission can trigger two emails: * **New submission notice**: "Sent to you when someone submits a form." It goes to the addresses you list, up to five, or to the workspace owner. * **Respondent confirmation**: "Sent to the respondent to confirm you received their answers." Both start from the templates saved for your workspace, and any single form can break away and use its own copy. This page covers the per-form side, in the editor's **Connect** tab. The workspace-wide copy lives in [Notification emails (account templates)](/dforms/account/notifications.md). > **⚠️ Note:** Both emails are sent for **completed** submissions only. A partial submission never triggers them. The confirmation is also skipped when no answer in the submission looks like an email address, since there is nobody to send it to. *** **Step 1:** Open the form in the editor, click the **Connect** tab and scroll to **Emails**. Each card shows which copy it is using right now, a preview of its subject line, and a **Customize for this form** button.

The Emails section of the Connect tab with the New submission notice and Respondent confirmation cards, each marked Using the account template — Two cards, one per email. The badge reads **Using the account template** or **Custom for this form**.

*** **Step 2:** Click **Customize for this form** on the email you want to change. The card opens into an editor with **Send this email**, **Send to** (on the notice only), **Subject** and **Body**.

The New submission notice editor with the Send this email switch, the Send to list of addresses, a custom Subject and a custom Body written with variables — Write the copy for this form. **Send to** decides who gets the notice, and **Send this email** turns it off entirely for this form.

| Control | What it does | | ------------------------ | -------------------------------------------------------------------------------------------------------------------------- | | **Send this email** | "Turn off to stop sending this email entirely." Leave it on unless you want silence for this form. | | **Send to** | The addresses that receive the notice. See [Who receives the notice](#who-receives-the-notice). | | **Subject** | The subject line. Variables are allowed. | | **Body** | The message, written as plain text with line breaks. It is sent as a formatted email, with a plain-text version alongside. | | **Available variables** | Click a variable to insert it at the cursor. | | **Preview** | The same copy rendered with sample values, updated as you type. | | **Use account template** | Drops the custom copy and follows the workspace template again. | | **Save changes** | Saves the copy for this form. You will see **Notification email saved.** | *** ## Who receives the notice **Send to** lists the addresses that receive the **New submission notice**. *Each address receives its own copy of this email. Up to five addresses.* * **Add address** adds a row, up to five. **Remove address** deletes one. An address that is not valid shows *Enter a valid email address.* * With no addresses, the notice goes to the workspace owner: *No addresses yet, so this email goes to the workspace owner.* * On a form, the rows start from the workspace's list and the editor says *Following the account list. Editing it here sets one for this form only.* Change the rows and save to give this form its own list. Remove every row and save to send this form's notices to the workspace owner only. * The list is greyed out while **Send this email** is off. The **Respondent confirmation** has no **Send to**: it always goes to the respondent. *** **Step 3:** Insert variables instead of typing values by hand. Under **Available variables** the editor explains: "Click a variable to insert it. Each is replaced with the real value when the email is sent."

The Available variables buttons, including Submissions link and Answers, and the Preview panel showing the subject and body rendered with sample values and sample answers — Click a variable to drop it in. **Preview** shows the result as you type, sample answers included.

| Variable | Button | Becomes | | --------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------- | | `{{formName}}` | **Form name** | The form's name. | | `{{respondentEmail}}` | **Respondent email** | The email address the respondent gave. | | `{{score}}` | **Score** | The total score. | | `{{outcomeLabel}}` | **Outcome** | The heading of the matching outcome. | | `{{formLink}}` | **Submissions link** | A link to this form's **Submissions** page. New submission notice only: the button does not appear on the confirmation. | | `{{answers}}` | **Answers** | One "Question: answer" line per answered question, in the order of the form. In the email it shows as a two-column table. | > **💡 Tip:** **Preview** always uses sample values (a sample form name, `lead@acme.io`, a score of 15, the outcome "Qualified", three sample answers and a sample submissions link), not answers from this form. It is there to show where each variable lands, not to show a real submission. Anything that is not one of these six variables is left exactly as you typed it, so a stray `{{firstName}}` would arrive in the inbox as literal text. Stick to the buttons and you cannot get it wrong. The notice exists to carry the answers. When its body does not include `{{answers}}`, the editor warns *This email does not include {{answers}}, so the answers will not be in it. Insert the Answers variable to add them.* Custom notices written before this variable existed had `{{answers}}` added at the end of their body. *** **Step 4:** Click **Save changes**. The badge on the card flips to **Custom for this form**, and from now on this form ignores the account template for that email. To go back, click **Use account template** and confirm **Reset email template**: "Remove this form's custom copy and go back to the account template?"

The Reset email template confirmation dialog with Cancel and Use account template buttons — Confirming deletes this form's custom copy. The workspace template is untouched.

*** ## Which copy wins Each email resolves in this order: 1. **This form's custom copy**, when the card says **Custom for this form**. 2. **The account template**, saved in **Settings → Notifications** for the whole workspace. 3. **The built-in copy** shipped with dForms, when nobody has changed anything. Customizing an email copies the current subject, body and **Send this email** switch into the form. From then on the form keeps that copy, and changing the account template later never overwrites it. **Send to** works differently: a form follows the workspace's list until you change the rows on that form. With no list anywhere, the notice goes to the workspace owner. > **⚠️ Note:** Editing this copy, on a form or for the workspace, is limited to workspace **admins** and **owners**. See [Members & roles](/dforms/account/members-and-roles.md). ## Language * The **New submission notice** is written in the workspace owner's language, set in [Preferences (language)](/dforms/account/preferences.md). Every address on **Send to** gets it in that language. * The **Respondent confirmation** is written in the language the respondent saw the form in. ## Email history The **Email history** panel at the bottom of the **Emails** section counts what this form has sent. Click **View history** for the list: "The last deliveries this form made, newest first."

The Email history dialog listing two Delivered rows, submission_received and submission_confirmed, with timestamps — One completed submission, two emails: the notice to you and the confirmation to the respondent.

* **submission\_received** is the new submission notice, **submission\_confirmed** is the respondent confirmation. The notice has one row per address on **Send to**, so each copy is delivered, retried and listed on its own. * The pill on the left is the status: **Delivered**, **In progress**, **Failed** or **Skipped**. * Times are shown in your workspace timezone. * **Refresh** re-reads the list without closing the dialog; **Close** dismisses it. An email that is switched off, or a confirmation with no address to send to, is never queued, so it leaves no row at all. A **Skipped** row is rare: it is an email that was queued without anyone to address. Failures are retried automatically, so there is no resend button. See [Delivery, retries & history](/dforms/connect/delivery-and-retries.md). ## Good to know * Emails never hold up a respondent. They are queued after the submission is stored, so a slow mail provider cannot break your form. * The sender address is set by the dForms deployment. It cannot be changed per workspace or per form today. * Deleting a form also removes its custom email copy. * `{{respondentName}}` inserts the respondent's full name in the subject or body, next to the other variables. * The expand icon on the **Preview** opens a larger mock of the email as it lands in an inbox, with the answers laid out as a table. ## What's next * [Notification emails (account templates)](/dforms/account/notifications.md): the workspace-wide copy and **Send to** list every form starts from. * [Delivery, retries & history](/dforms/connect/delivery-and-retries.md): what **Delivered**, **Failed** and **Skipped** mean. * [Outcomes (results by score range)](/dforms/logic/outcomes.md): what `{{outcomeLabel}}` is filled with. * [Submissions](/dforms/results/submissions.md): read the answers behind an email. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.dapta.ai/dforms/connect/emails.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.