> ## Documentation Index > Fetch the complete documentation index at: https://help.the-meridian.ai/llms.txt > Use this file to discover all available pages before exploring further. # Introduction 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](/send-email#choosing-the-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](/automation-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](/automation-variables#event-properties) of a tracked usage event, as `{{properties.}}`), your own [custom fields](/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](/emails#active-and-inactive). * **Deleting** is permanent, and needs a [role](/collaborators) 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](/automation-test-runs) from the automation that uses it and give it your address. The test sends the email as last saved, so save your changes first. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.