E-mail Templates

An E-mail Template is a reusable message body with merge tokens. Once defined, a template can be referenced from any feature that sends mail — UIVs, Tasks, Carts, Password Resets, custom callbacks. Centralising message bodies as templates means you can refine your wording once and have every feature benefit, without hunting through PHP code.

Anatomy of a template

Every template has:

• Name — internal identifier, also shown in dropdowns when picking a template.
• Subject — the email subject line, supports merge tokens.
• Body — the message body, in HTML, supports merge tokens. The platform automatically generates a plain-text version from the HTML if you don't supply one explicitly.
• From Address (optional override) — which E-mail Account sends this template by default. Leave blank to use the sending feature's default.
• Reply-To (optional override) — set a reply-to header on outbound messages.
• Attachments (optional) — files that should always be attached to messages sent with this template.

Merge tokens

Tokens in the template body are substituted at send time with values from the relevant row. The standard tokens:

• ##AMDATA_fieldname## — any field on the row.
• ##AMDATA_ID## — the row's ID (useful for reference numbers, URLs).
• ##SITE_URL## — the platform's base URL.
• ##SITE_NAME## — the configured website title.
• ##RECIPIENT_EMAIL## — the email address the message is being sent to.
• ##RECIPIENT_NAME## — the recipient's name (if known from their user account).

Feature-specific tokens add to the standard set. UIVs add ##REFNUMBER##, ##STAGENAME##, ##REQUESTURL##. Password resets add ##RESETURL##, ##EXPIRESIN##. Carts add ##ORDERTOTAL##, ##LINEITEMS##. See each feature's documentation for the specific tokens.

Where templates live

Architect Panel → E-mail Templates. The list shows every template with name, subject preview, and a count of how many features reference it.

Three real-world template patterns

Pattern 1: Simple transactional

One template per type of transactional email — Password Reset, Welcome, Order Confirmation. Each has a friendly subject, branded body, and clear next-step call-to-action.

Pattern 2: Per-tenant branded

For multi-tenant SaaS, each tenant can have their own version of a base template (e.g. Confirmation Email). The Conditional Form logic on the template picks the right variant based on the recipient's tenant.

Pattern 3: Heavily-templated multi-language

For multi-language apps, one template per language per email type. So "Password Reset (English)", "Password Reset (French)", "Password Reset (German)". The platform picks based on the recipient's language preference.

Templates can reference data via merge tokens. The set of available tokens depends on the context the template is rendered in — different features expose different tokens. Knowing what's available means you can pull in the exact data you need without falling back to hand-coding values.

Universal tokens (always available)

• ##AMDATA_ID## — the row ID (integer).
• ##AMDATA_fieldname## — any field on the relevant row, by row name. So if your datastore has a companyname field, use ##AMDATA_companyname##.
• ##SITE_URL## — the platform's base URL (e.g. https://app.acme.com).
• ##SITE_NAME## — the configured website title.
• ##RECIPIENT_EMAIL## — the email address the message is being sent to.
• ##RECIPIENT_NAME## — the recipient's name (if known).
• ##NOW## — current timestamp formatted per Site Settings → Date/Time.
• ##TODAY## — current date.

UIV-specific tokens

When the template is sent in the context of a UIV stage:

• ##REFNUMBER## — the request's reference number (with prefix).
• ##STAGENAME## — the name of the stage the request is at.
• ##STAGENUM## — the numeric stage number.
• ##REQUESTURL## — direct link to the request's stage page.
• ##AUTHORISER_NAME## — the current stage's assigned authoriser.
• ##REQUESTER_NAME## — the person who submitted the request.
• ##NOTES## — any notes the authoriser added when actioning the stage.

Password reset tokens

When the template is a password reset email:

• ##RESETURL## — the unique reset link.
• ##EXPIRESIN## — when the link expires (in minutes).
• ##USER_NAME## — the user's display name.

Cart tokens

When the template is sent in the context of an eCommerce order:

• ##ORDERTOTAL## — formatted total.
• ##LINEITEMS## — formatted list of items (HTML or plain depending on template).
• ##ORDER_REF## — order reference number.
• ##SHIPPING_ADDRESS## — formatted shipping address.
• ##BILLING_ADDRESS## — formatted billing address.
• ##PAYMENT_METHOD## — the payment method used.

Date/time formatting in tokens

Date and DateTime fields render in the format configured in Site Settings → Date/Time. For custom formatting per template, use the platform's date-formatting helper in a custom function and return a pre-formatted string.

Conditional content

For conditional sections in templates ("if status is X, show this paragraph; if Y, show that paragraph"), the platform's template syntax supports basic conditionals. Use HTML comments combined with ##IF_## tokens, or for complex logic delegate to a Custom PHP Code field that returns the right HTML based on row data.

Three real-world templates with tokens

Example 1: UIV approval email

Subject: Your request ##REFNUMBER## was approved

Body: "Hi ##REQUESTER_NAME##, your request ##REFNUMBER## for ##AMDATA_subject## was approved by ##AUTHORISER_NAME##. ##NOTES##. View the request at ##REQUESTURL##."

Example 2: Welcome email

Subject: Welcome to ##SITE_NAME##

Body: "Hi ##RECIPIENT_NAME##, welcome to ##SITE_NAME##! Your account is now active. Sign in at ##SITE_URL## to get started."

Example 3: Order confirmation

Subject: Order ##ORDER_REF## confirmed

Body: "Thanks for your order, ##RECIPIENT_NAME##. Your order ##ORDER_REF## for ##ORDERTOTAL## is confirmed. Items: ##LINEITEMS##. We'll ship to: ##SHIPPING_ADDRESS##."

Before launching a template into production, send a test email to yourself. Catching rendering issues, broken tokens, or formatting problems in a test is much cheaper than discovering them after the first 100 real users have received the broken version.

From the template editor

Each E-mail Template has a Send Test button. Click it and you get a small dialog asking for:

• Recipient — your own email address.
• Sample row (optional) — a specific row from the relevant datastore to populate the merge tokens with real data. If left blank, tokens get sample values like "[Sample Customer Name]".

The platform sends the test message using the same path as a real send — same template, same E-mail Account, same merge processing. So if it looks right in your inbox, it'll look right for real users.

What to check in the test

1. Subject line

Does it render correctly with substituted tokens? Is it the right length (under ~60 characters for good inbox preview behaviour)? Does it pass spam-filter sanity checks (no excessive punctuation, no all-caps)?

2. Body HTML

Does it display as expected? Check both light-mode and dark-mode email clients — many email apps invert backgrounds in dark mode, which can break designs that assume white backgrounds.

3. Links

Are they clickable? Do they point to the right URLs? Are tokens correctly substituted (no literal ##URLTOKEN## appearing)?

4. Images

Do they load? Configure them as absolute URLs to your site (not relative paths — relative paths break when the email is opened on the recipient's mail server, not yours).

5. Plain-text alternative

Many email clients (and some recipients) prefer or require the plain-text version. The platform auto-generates one from the HTML — check it makes sense (no orphan tags, links shown as full URLs).

6. Spam score

A tool like mail-tester.com gives a quick spam audit. Forward your test email to the address they provide and they'll score it 0-10 with specific advice on what to improve.

Three real-world test patterns

Pattern 1: Final-design review

After completing a new template, send a test to a small review group (3-5 people). Each views in their preferred email client. Collect feedback on rendering, tone, length, and any issues that catch the human eye.

Pattern 2: Multi-client check

For templates that'll go to consumer audiences, test in Gmail (web and mobile), Apple Mail, Outlook (web and desktop). Each has slightly different CSS support and quirks. Litmus and Email on Acid are paid tools that automate this across many clients.

Pattern 3: Token-substitution check

For templates with many tokens, test with a sample row that has values in every relevant field. Spot any tokens that aren't substituting (rendering literally) or substituting incorrectly (wrong field, escape issues).

Tip: Make test-emails part of your template change workflow. Every meaningful template edit should be followed by sending one test to yourself before considering the change done. The 30 seconds it takes to send and review prevents the embarrassing "hi ##FIRSTNAME##" emails everyone receives at some point.