​

The email library

An email in Notifizz is not a file you edit once and copy for the next campaign. It is a layout — the envelope — with an ordered stack of sections inside it, drawing on the images in your assets library. Build the blocks once; every campaign composes from them. This page is written for the marketing side of the team: what the pieces are, who decides what, and what your plan caps. The parts that only a developer touches — the component contract, the save-time checks — are marked as such and kept short.

​

TL;DR

• A layout is the envelope: header, page background, the centred frame, and the footer with the unsubscribe link. Your organisation always has exactly one default layout, and it is seeded for you on day one.
• A section is a content block inside that envelope — a heading, a paragraph, a button, an image. An email is an ordered stack of them.
• An asset is an image in your organisation’s gallery, referenced by the layouts and sections that display it.
• Four sections ship built in — Text, Image, Button, Spacer — and the button already renders in your brand colour. Most organisations need a handful of custom sections on top, not dozens.
• Every property is typed, and each type gets its own control in the editor: an image picker, a markdown field, a colour picker, a date picker, a CTA destination.
• Brand chrome can be marked private — frozen to its value and hidden from whoever reuses the block, so nobody is asked about your logo again.
• Publishing freezes a component. Campaigns pin the version they were built against, so improving a block never rewrites an email that already shipped.
• Layouts, sections and stored assets are capped by your plan. The ceiling applies to new creations only — nothing you already own is ever taken away.

​

The three pieces

A layout and a section are the same kind of object under the hood — the difference is that a layout owns the page and reserves a slot for children, and a section owns nothing but its own block. That difference is fixed at creation: a component’s kind can never change. A section will never become a layout; make a new one instead.

​

How an email is composed

A campaign’s email step holds a subject line, a layout, and the ordered list of sections. Nothing else. Pick no layout and your organisation’s default is used. Two consequences worth internalising:

• Sections never set their own width or side margins. The layout owns the column, so every section lines up on the same edge no matter who wrote it. A section only controls its own vertical rhythm — the gap to its neighbours above and below.
• Reordering is free. Because a section is a fragment and not a whole document, moving it up or down cannot break the page.

​

Properties: what changes per send, what stays fixed

Every section and layout declares its properties — the values it reads. They are typed, and the type decides the control the editor shows: Two properties of the same block are not equal in status:

• Public properties are content. Headline, body copy, button label and destination, images, amounts, dates, list items — anything that changes from one campaign to the next. They stay editable by whoever composes the email.
• Private properties are brand chrome. Logo, brand colour, legal footer line, fixed structural styling. Marking a property private freezes it to its value and hides it from the composer — and from the AI. A campaign author is never re-asked about your logo, and cannot break it by accident.

Default values are copied into a block at the moment you place it in an email. Change the component’s defaults later and existing placements keep the values they were given — no silent rewrite of an email you already approved.

​

What ships with every organisation

One default layout, created with your organisation and named Base: a white card on a light ground, a brand wordmark, the slot, and a compliant footer. It is ready to send as-is, and it already satisfies the unsubscribe rule below. Four built-in sections, which no plan counts and nobody can delete: They are the reason a healthy library is small. Before anyone builds a “Paragraph” section, a “Bulleted list” section and a “Link” section, note that the built-in Text block is all three. What genuinely justifies a custom section is what markdown cannot express: a styled heading, and anything sitting on a coloured block background.

​

Brand tokens

Rather than pasting your colours into every block, components reference tokens that Notifizz substitutes when the email is rendered: Set them once in your brand settings and every block that uses a token follows — including the built-in button. Hard-coding a colour into a component severs that link and the block stops following a rebrand; see brands and variables.

​

The default layout, and the unsubscribe rule

Your organisation always has exactly one default layout. Setting another layout as the default is a swap, performed in one write: there is never a moment with none. Two consequences the dashboard will hold you to:

• The current default cannot be archived. Promote another layout first, then archive it.
• The default cannot be cleared, only replaced.

A layout cannot be published without an unsubscribe link. Exactly one footer link, whose destination is the reserved placeholder {{notifizz:unsubscribe}}. The wording is yours — Unsubscribe, Manage my preferences, anything. The destination is not:

• Notifizz fills it per recipient, so it can never point at the wrong preference page.
• It is stripped entirely on transactional sends, which carry no unsubscribe surface.
• A second, hard-coded unsubscribe link is refused, because it would survive that strip and mail a dead link to a real person.

This is checked when you publish, and enforced again at render. See privacy friendly for what happens on the other side of that link.

​

Lifecycle: Editing, then Live

A component is in one of two working states, plus an archive: Publishing freezes the block. It leaves the editor, and its default values can no longer be changed — an attempt to rewrite them is refused. To change something afterwards, create a new version: the published version is frozen as an immutable snapshot, and the head returns to Editing one version up, ready to edit and republish. Meanwhile, each placement pins the version it was composed against. A campaign built on version 2 keeps rendering version 2 even after version 3 is published, and keeps rendering it identically a year later. Upgrading a placement is a decision, not a side effect. Renaming a component changes its display name only, in any state. Its key — the identity every existing placement resolves through — never changes.

​

Two checks before anything is saved

Every save — by hand, by the AI editor, or by the migration assistant — passes the same two gates:

1. A code check. Only React and the email component library may be imported. Dynamic imports, eval, raw HTML injection and prototype access are refused outright. An email is rendered with your recipients’ data in it; unescaped HTML in that position is not a stylistic preference.
2. A render check, through the send path. The component is rendered once, with nothing but its own defaults, using the very engine that renders your real emails. If it fails, the save is refused with the exact error — and the author, human or AI, can fix it immediately.

The second one exists because a preview that works proves nothing about a send that does not. A block that cannot render must never become the version a campaign resolves at delivery time.

​

Assets

The gallery is one image library per organisation, organised in nested folders. Images attached to the editor’s AI chat as visual references are stored in the same place and count the same way.

​

What your plan caps

Three of the library’s objects are metered as stock — a ceiling on what your organisation owns, not on what it sends: Four rules make this predictable:

• The count is live. Archive a section or delete an image and the capacity comes back immediately.
• Only creation is ever refused, with an explicit error naming the resource and its ceiling. Editing, publishing and sending are never blocked by a stock limit.
• If a plan change puts you above a ceiling, nothing is taken away. You keep everything; you simply cannot add until you are back under.
• Your current figures are in the Billing & usage view, under Stored resources, next to your send volumes.

​

Authoring with the AI editor

Each component has its own editing conversation: describe the block you want, attach a screenshot or a reference image, and the editor writes it — typed properties, editor controls, public/private split and all. It asks a question only when the answer would change the block’s shape, and it always returns a working preview in the meantime. Each request draws one AI credit from your organisation’s pool. When the pool is empty the editor says so and tells you when it refills. For a whole existing template set, don’t do it block by block — see migrating your existing email templates.

​

FAQ

​

See also