Reusable blocks

Saving one row of an email so it can be dropped into any template — how blocks are stored, why they are copies rather than live includes, and the two init-time rules that decide whether the Blocks panel appears at all.

5 min readUpdated 3 August 2026blocks, templates, editor

A block is one saved row of an email — a branded header, a footer with your company details, a product card, a signature. Build it once and it appears in the template editor's Blocks panel for every template you touch afterwards.

Blocks live at Admin → MailWizard → Blocks, /admin/mailwizard/block. They arrived in v6.2.0; the storage existed earlier with nothing connected to it, so if you are upgrading there is nothing to migrate — the table has always been empty.

What a block is, exactly

The editor's unit of layout is a row: a full-width horizontal band split into one or more columns, with content items inside those columns. A block is one such row, stored as the editor's own JSON.

That is the whole model, and two things follow from it.

A block that stores several rows contributes each of them separately. Saving the "entire design" of a four-row template produces four entries in the Blocks panel, not one. If you want a multi-row unit to stay together, it cannot — the panel's unit is the row.

A block is not an HTML snippet. It is stored as design JSON precisely so the editor can open it and keep editing it. Exporting HTML at save time would produce something the editor could never edit again.

Creating a block

There are two routes in, and they suit different moments.

From the Blocks screen — Blocks → Create opens the same drag-and-drop editor on a blank canvas, with a name and category above it. Build the row, name it, save. The editor refuses to save an empty canvas: a block with no rows would appear in the panel and insert nothing.
From inside a template — while editing any template, press the Save as block button in the toolbar. A dialog reads your current design and lets you pick which row to keep, describing each one by its column count and the kinds of content in it, so you are choosing "Row 2 — 3 columns, image, text" rather than guessing between "Row 1" and "Row 2".

The template you are editing is not modified by Save as block. Nothing is moved, cut or changed — the row is copied out.

Blocks are copies, not live includes

Inserting a block copies its rows into the template. From that moment the two are unrelated: editing the block later changes what future insertions produce and nothing else.

This is deliberate. A live include would silently rewrite emails that had already been reviewed, approved and, in some cases, already sent — a footer change would retroactively alter the content of an in-flight campaign.

The practical consequence is that changing a footer across ten templates is ten edits. Plan the blocks you expect to change — legal text, an address, a support link — to be as small as possible, so re-inserting one is quick.

Deleting a block is equally inert: templates that already used it are untouched.

Why the Blocks panel sometimes is not there

The editor reads its list of blocks once, at initialisation, and offers no way to change it afterwards. Three behaviours follow, and all three look like bugs until you know the rule.

With nothing saved, the Blocks panel is switched off rather than shown empty. An empty panel reads as "this feature is broken"; an absent one reads as "not in use yet". Save one block and it appears on the next editor load.

Because the list is fixed at init, a block saved from Save as block cannot appear in the panel of the session that created it. The success toast therefore carries a Reload editor action. Taking it re-initialises the editor with the new block and carries your current design across — including unsaved changes, which stay unsaved. Ignoring it is fine too; the block is stored either way and will be there next time.

Loading a template shows a spinner until the block list has been fetched, because mounting the editor first would leave the panel empty for the whole session. If the block endpoint fails the editor still opens — a blocks outage must not cost you your template editor — you simply get no panel.

The block list is permission-gated like everything else. An admin who can edit templates but holds no block permissions gets a working editor with no Blocks panel and no explanation. Grant view.mailwizard.block alongside the template keys.

Managing saved blocks

The Blocks screen is a normal admin table: create, edit, delete, bulk delete. Editing a block reopens it in the editor as a one-row design; saving writes the row back.

The view dialog shows what the block actually contains — its rows, their column counts and the content types inside them — which is far quicker than opening the editor when you are trying to work out which of three similarly named headers is the current one.

The create and update endpoints refuse anything that is not a JSON object — a bare string, an array, null. This is stricter than the check on a template body and it is stricter for a reason: a malformed entry does not produce one broken block, it stops the editor's whole Blocks panel from rendering, with nothing anywhere saying why. Refusing it at the door is the only place that can be explained.

If you are writing blocks through the API rather than the editor, send the full design shape — an object with a body holding a rows array — and it will load correctly in both directions.

A sensible block library

For most operators three or four blocks cover everything:

Block	Category	Why it earns its place
Branded header	`Headers`	Logo, background colour, spacing — the part nobody wants to rebuild
Legal footer	`Legal`	Company name, address, and the unsubscribe link you have to add by hand, since nothing injects one
Call-to-action row	`Content`	A button styled once, correctly, with the right colours and padding
Signature	`Content`	A named human, which measurably helps a marketing email look less like bulk

The footer is the one that matters most. Campaign email does not pass through the platform's notification templating, so no unsubscribe URL is added for you — see How sending works. Putting that link in a block is the only way to be sure every template carries it.

Next: Building and sending a campaign.