Notifications

Email templates a form's rules and workflow transitions can send. Written once, referenced by slug, versioned like everything else — and queued rather than sent inline, so a mail server having a bad afternoon never costs you a submission.

Writing a template

Templates live under Notifications (notification:read to see them, notification:write to edit). Each has a slug — that is what a rule references — a subject line, and a body built from the same blocks as documents.

Merge values by wrapping a field slug in double braces, in the subject as well as the body:

Order {{reference}} received

A placeholder whose value is missing renders as nothing rather than leaving braces in the email. Editing a live template starts a draft; publishing makes a new version and leaves everything already sent alone.

Where AI is configured, the editor can draft the email for you — describe it, pick the form whose fields it should merge, or hand it a document to turn into the email version. The subject line comes back with the body, and both land in the editor unsaved for your review. Email cannot carry embedded images or page breaks, so a reproduced document keeps its wording, structure and tables and says plainly what it left behind.

What you can merge in

• Anything the submitter typed, by field slug.
• Anything the server computed — totals and other computed fields, the allocated reference number, values a workflow transition set, and payment status.
• {{download_link}} when the submission has files to claim — one link regardless of how many files, since the claim page lists them.

Payment-request emails are the exception worth knowing: they carry {{payment_link}}, {{payment_amount}} and {{payment_currency}} and nothing else — a field slug referenced in that particular template renders blank.

Two kinds of recipient

The template itself can carry fixed addresses — the ops inbox that should see every one of these. The rule or transition that sends it can add dynamic recipients, written as:

field: is how you reach an anonymous submitter: a public form has no creator, owner or assignee, so the address they typed is the only way to write to them. A field value that is not a valid email address is skipped — everyone else still receives the message — and a list field's fan-out is capped at twenty addresses, because a submitter-controlled list must not be able to turn one submission into a mailing.

Publishing checks every recipient: a descriptor that is not one of the four above, or a field: naming a slug the form does not have, is refused at publish time rather than discovered when nothing arrives.

Email is not a document

Two blocks are refused in an email template, with the reason given at publish: images, because mail clients strip them, and page breaks, because an email has no pages. Everything else — headings, lists, tables, conditions, repeats, bold, italic, underline and links — behaves as it does in a document.

The outbox

Sending is queued, never inline. A notification becomes a row that a sender drains on a schedule, retrying up to five times before it is marked failed with the reason kept. You can see exactly what happened on the submission's own Activity tab, where queued messages show as Queued alongside integration deliveries and agent runs.

This is why an unreachable mail server never breaks a submission: the record is already saved, and the email is a row waiting its turn.

When mail does not arrive

• Sending may be switched off for the deployment. Messages queue and wait rather than being lost — ask your operator whether mail is enabled.
• The monthly email allowance may be used up. Over-allowance messages are held, not discarded: they send when the month rolls over or the plan grows, and a banner tells account holders. Account email — password resets, invitations — is never held.
• No recipient resolved. A message with nobody to send to fails immediately and says so.
• A template that has been archived is skipped by the rules that reference it, and forms cannot be published referencing one.

When mail arrives in spam

Every message Faldaro sends is structured the way filters want it — HTML with a plain-text twin carrying the same links — so a spam verdict almost always means the sending domain is not authenticated. That is deployment configuration, not template content: the From address must be on a domain the deployment controls (never a gmail.com address relayed through another server, which fails alignment by definition), that domain's DNS must authorise the relay (SPF), sign the mail as itself (DKIM), and publish a DMARC record — Gmail requires one of bulk senders outright. Open a received message's Show original in Gmail: SPF, DKIM and DMARC should each say PASS with your domain named. Self-hosting? The operations runbook walks through the exact records per provider.

Content plays a smaller part, but a signing or payment mail is one long tokenised link — exactly the shape phishing takes — so give the template a sentence of real context around it: who is asking, for what, on which form. A near-empty body with a bare link earns suspicion a normal message never sees.