# System emails

> The emails your project sends on its own — sign-in codes, invites, order receipts — and how to change their look, test them and reset them.

Source: https://knowledge.estage.com/email/system-emails/
Part of the ESTAGE knowledge base (https://knowledge.estage.com). Full corpus: https://knowledge.estage.com/llms-full.txt

---
**System emails** are the messages your project sends without anyone composing them: the
sign-in code, a team invite, a booking confirmation, a store receipt. Each one goes out in a
standard ESTAGE design until you customize it, so you can make them look like the rest of your
mail.

Open **Messages** and click the **System emails** card at the top of the list, next to your
folders. **Messages** in the breadcrumb takes you back.

## How they differ from your other email

System emails are **transactional**. Whoever sends them:

- they **don't spend your [sending allowance](/email/allowance/)**;
- they carry **no unsubscribe footer and no tracking**;
- customizing one changes how it looks, not how it travels.

## Who they come from

The card above the list shows the address that signs every system email, badged **From your
project** or **From Estage**.

- With no verified sender, they send from ESTAGE. The card links to setting up a domain and a
  [sending address](/email/senders/) so they arrive from your own.
- Once you have one, they use your default sender — or, if there's none, the address most of your
  automations send from, or your only verified address. The card says which rule picked it.
- Pick a different verified address from the dropdown to set one aside for system emails. This
  doesn't change your default sender; broadcasts and automations keep theirs. Addresses still
  waiting on verification can't be picked.

## The list

The emails are grouped by what sets them off, and each row carries the email's name:

| Group | Emails |
| --- | --- |
| **Signing in** | Login verification code (OTP) · Signup email confirmation · Password reset |
| **Your project** | New member signup (to owner) · Project team invitation · Contact form submission · Meeting booking confirmation · Autoresponder import finished · Broadcast paused by the health check · Automation: notify admin by email (to the owner) |
| **Store** | Store order confirmation · Store order shipped · Store order refund notice · Store abandoned cart reminder · Store: new order (to the owner) · Store purchase order (to a supplier) |
| **Community** | Community membership approved · Community membership denied · IPS license approved · IPS activation denied · IPS license revoked |
| **Other** | Store order delivered |

**Other** holds emails newer than the grouping; they work the same way as the rest. *Store order
delivered* goes to the buyer once per parcel, when the carrier reports it delivered.

Each row shows who the email **Goes to** (for example *You*, *Buyer*, *Member*, *Supplier*), its
**Status** — **Default** or **Customized** — and when it was **Last edited**. An info icon on a
row explains anything the row can't, such as how often it sends or which setting switches it on.

## Customizing one

1. Click **Customize** on the row.
2. Confirm with **Customize it**. A copy of the standard email becomes yours, already carrying
   every variable the email can't send without. The standard one is left untouched.
3. The copy opens in the message editor. Change it and click **Publish** — from then on it goes
   out instead of the default.

The editor shows a strip above the email: *"Sends through Estage — no allowance spent, no
unsubscribe footer, no tracking"*, and **Must keep** with the variables this email needs — for
example `{{code}}` in a sign-in email. Remove one and you're warned before saving; save anyway and
the save is refused until you put it back. The merge-field menu offers the variables this
particular email carries.

Once customized, the row's button reads **Edit** and opens your copy. Customized templates are
kept in a **System Emails** folder under Messages, which the list doesn't show separately — the
card is the way in.

:::note
A customized email left as a **Draft** doesn't stop the email: it keeps sending in the standard
design until your version is published.
:::

## Previewing and testing

From a row's **⋯** menu:

- **Preview** — the email as recipients get it today, default or customized, with an **HTML** tab
  showing the source with its variables still in place.
- **Send a test** — sends it with sample values to the address you enter. The subject arrives
  prefixed with **[TEST]**, and it doesn't spend your allowance.

## Resetting to default

**Reset to default**, in the **⋯** menu of a customized row, puts the standard ESTAGE email back.
Your template isn't deleted — it stays in the System Emails folder under Messages.

## Things worth knowing

- **Community emails keep the standard design.** The five Community emails are sent from
  Community itself, so the standard email is what goes out even if you customize one — a clock
  icon on those rows says so.
- **Bookings: only the confirmation.** Cancellations, reschedules and reminders keep the standard
  email. The calendar invite rides on the confirmation, reschedule and cancellation either way;
  reminders carry none. See [Bookings](/crm/bookings/).
- **The abandoned-cart email** only sends while *Send a recovery email* is on in the store
  settings. With it off, an abandoned cart still fires the **Store cart abandoned**
  [automation](/email/automations/) trigger.
- **Shipped and refunded** send once per shipment and once per recorded refund. Recording a refund
  doesn't move money — the payment gateway does.
- **The new-order notice and purchase orders** go to you and to a supplier, not to the buyer, so
  contact merge fields in them come out empty or carry your own details.