---
title: "Email notifications"
description: "Receive selected answers in your team inbox, reply directly to respondents, and track notification delivery."
group: "Deliver & operate"
order: 3
type: "feature"
keywords:
  - "email"
  - "notification"
  - "receipt"
  - "notifyEmail"
  - "sendReceipt"
updated: "2026-10-10"
---

Fillo can email one team address about each accepted response or a persistent delivery failure, and can send a confirmation receipt to the first answered email field.

## Team notification email

Open the form's **Integrations**, choose **Email**, and enter the team address that owns the next action. The address autosaves and controls new-response mail; clear it to stop those messages. Fillo can also alert that address when a destination stays in a persistent failed state. If the address is empty, persistent delivery-failure alerts fall back to the workspace owner.

Use a team inbox when several people share the work. The email is a handoff signal, not your system of record — review and delete data in Fillo or the downstream destination, not from an email copy.

By default, **Email content** is **Link only**: answers stay in Fillo. Choose **Include answers** to copy selected answered fields into each email. Unanswered fields are omitted; hidden fields are excluded unless you select them. Long answers are shortened; open the response in Fillo for the full content. Uploads appear as filenames, with access through the authenticated response in Fillo; no files or public download links are attached.

Choose an email field under **Reply to** so clicking Reply in your mailbox addresses the respondent. Fillo sends from its own verified address, and uses the selected answer only as Reply-To. Missing or invalid answers do not supply a respondent reply address. Typed answers do not prove inbox ownership. Notifications label the reply address as unverified unless a live, project-scoped email-confirmation session matches it. Replies sent from your mailbox are not recorded in Fillo.

With **Include answers** and a valid respondent reply address, the email body contains your selected questions and answers in plain text, followed by a short “Sent via Fillo” footer linking to fillo.so. Unverified reply addresses carry a short notice so your team can assess the sender before replying. If no selected fields are answered, it says that no answers were included. **Link only** keeps answers private, even when **Reply to** is configured. Notifications without a valid respondent reply address keep their link to the response.

Every notification has a distinct response id in its subject. Answer content is an explicit opt-in, available on every plan. Email copies remain in recipients' mail systems when you delete the response in Fillo.

## Respondent receipt

Enable the receipt when respondents need confirmation that Fillo accepted the form. The renderer uses the first answered email field, so make that field required if every response needs a receipt destination.

Receipts use fixed Fillo text without answer content, owner-controlled titles, or custom success messages. They tell unexpected recipients that no action is required. Each address can receive at most three receipts per hour across all forms and workspaces; workspace caps also apply. These limits persist across restarts and replicas.

## Code-defined forms

`notifyEmail`, `notifyEmailIncludeAnswers`, `notifyEmailAnswerFields`, `notifyEmailReplyToField`, and `sendReceipt` exist in `FormSettings`, but public publishable-key sync strips incoming values for these settings. They trigger server-side mail, so they stay dashboard-owned on synced forms.

Define and sync the form structure in code, then configure notifications in the dashboard. A stale code deployment won't overwrite the dashboard values.

```ts
const request = defineForm({
  id: "support-request",
  pages: [{
    id: "main",
    blocks: [
      { id: "email", kind: "email", label: "Email", required: true },
      { id: "issue", kind: "long_text", label: "What happened?", required: true },
    ],
  }],
});
```

## Trust, updates, and limits

A held unverified submission sends no team notification and no receipt. Releasing it runs the normal accepted-response notification flow.

An update-in-place response sends an updated-response notification with that occurrence's answers. Fillo supports one team address, which can be a shared inbox or distribution group. For conditional recipients, custom templates, attachments, or escalation rules, use a signed webhook, Zapier, or another destination.

Team notification jobs are saved in the same transaction as the accepted response. Temporary failures retry up to six attempts. The Responses delivery column shows pending, sent, or failed; **Retry failed** retries the latest failed email, and **Re-send** queues a new notification. Sent means the mail provider accepted the message, not proof it reached the inbox.

Each automatic retry preserves the original answers and labels, with a stable provider idempotency key. Disabling notifications or changing their recipient/content/reply configuration cancels unsent jobs from the prior configuration. Deleting a response erases its queued email copies and prevents future delivery. Respondent receipts remain separate from the team notification outbox.

## Plan status

The team notification email and respondent receipts are available on every plan, Free included.

## Related

- [Integrations](/docs/integrations): Choose a durable destination for the next action.
- [Submission trust](/docs/trust): See why held submissions don't send mail.
- [Webhooks](/docs/webhooks): Build conditional server-side notification logic.