Skip to main content
The email builder is where an email is designed. You pick how you want to author it when the email is created, and that choice is fixed: the two modes aren’t convertible, because one stores a block document and the other stores your own markup.

Visual editor

A drag-and-drop canvas of blocks. Select any text to format it, type / to insert a block or a variable, or drag blocks in from the Blocks tab of the left panel. Its Structure tab shows the email as a tree of blocks, to select and reorder them. The right panel inspects whatever you’ve selected, and a breadcrumb shows where you are in the document. The editor keeps its own undo and redo history, and a switch in the top bar previews the canvas at desktop or mobile width. Images are inserted through the image picker. A file you upload there is hosted by Meridian, so the email doesn’t depend on a URL you might later move. The picker also takes an image URL, which is used as is: that image stays wherever it’s hosted.

Custom HTML

Paste or write the email’s HTML yourself. Use it when you already have a templating system, need markup Meridian’s blocks don’t produce, or want exact control for a client’s brand. The source sits next to a live preview, filled with sample values or with a store of yours, and the same desktop and mobile switch sets the width it renders at. Undo and redo there are the source editor’s own, on the usual keyboard shortcuts. The source can be up to 512 KB. A custom-HTML email carries its own preheader in the markup, so Meridian doesn’t offer a preview text field for it.

Saving

The builder saves when you click Save or press Cmd+S (Ctrl+S on Windows), never on its own. Save stays disabled until there’s a change to save. While a save runs the top bar shows Saving, then Saved just now, Saved 5 min ago, or the date of the last save. A save that fails says why and leaves your changes in the editor, still unsaved. Following a link out of the editor with unsaved changes asks you to confirm first, and so does closing or reloading the tab. If your session expires while changes are unsaved, you sign back in without leaving the page, and the save goes through. Each save updates, at once, every automation step that sends the email, active or not, so the next run sends the saved version. When more than one automation sends it, the top bar shows how many, and clicking the count lists them. To rework an email that a live flow sends, edit a duplicate instead. See Send email.

Subject and preview text

The subject is what the inbox shows as the headline, and it’s required before the email can be activated. Preview text is the line after it. Both accept variables, inserted from the picker attached to the field, so a subject can name the store or the plan. Edit them on the email’s page, where a field saves as soon as you leave it or press Enter, or in the editor from Rename (or by clicking the email’s name in the top bar), which saves the name, subject and preview text together when you confirm. Neither waits for Save, and both reach the automations that send the email the same way a design save does.

Variables

Anywhere text is edited (subject, preview text, body) you can insert a variable: the store’s details, whatever the triggering event carried (including the properties of a tracked usage event, as {{properties.<name>}}), your own custom fields, or the recipient’s name. They’re substituted at send time. A token that no longer exists renders as an empty string rather than leaking {{braces}} to a merchant. Each trigger supplies its own variables, so the same token can fill on one automation and arrive empty on another. The editor’s top bar counts the variables that will arrive empty on at least one of the automations that send the email, and clicking the count shows where each one is used and which automations miss it.

Managing the email

Rename, duplicate or delete it from More actions, on the email’s page or in the editor, and activate or deactivate it with the Activate or Deactivate button next to it. The name is internal, shown in the list and the send logs.
  • Duplicate makes an inactive copy, named after the original with (copy) added. In the editor, unsaved changes go into the copy, which opens next. The original stays as it was last saved, so the automations that send it keep sending that version.
  • Activating needs a subject. In the editor, activating an email without one opens a dialog that says why and takes the subject right there. On the email’s page, the subject field asks for one. When some of the automations that send the email would send variables empty, activating names them first, and you can activate anyway. What deactivating does to those automations is on Active and inactive.
  • Deleting is permanent, and needs a role that allows it: without one, the menu entry is hidden. When automations use the email, the confirmation lists them and warns that deleting breaks them, and any active ones are paused as part of the delete.
To see the design filled with real values and actually delivered to yourself, run a test from the automation that uses it and give it your address. The test sends the email as last saved, so save your changes first.
Last modified on September 30, 2026