Skip to main content
A component library is your approved set of building blocks — a hero, a CTA button, a feature row, a footer — each carrying a note on when it should be used. There are two, because email and web are different craft: Creating a library is the step that does the most work later. Once one exists, everything composed from it is checked against it. For how Email Components fit with email templates and emails, see the Email overview. To edit or write email components, see Email components.

​
Create one

1

Create the library

In Content, select Create and choose Email Components or Page Components. Give it your brand guideline and, if you have one, an email or page that already looks the way you want.Working from an asset you already have is usually faster than describing blocks from scratch — the generator pulls the recurring pieces out of it and writes them up as components.
2

Review the blocks

You get an index of blocks, each with a name, a short description and a rendered preview. Each block also carries guidance on when to use it, which is written for the generator and isn’t shown on the card.The guidance is not decoration. It is what the generator reads when it is choosing and composing. A block described as “hero — use at the top of a launch announcement, never more than one per email” produces better output than one called “hero1”.
Scrolling through a page component library, with each block's name, description and preview

Scrolling through a page component library: each block's name, description and preview.

3

Publish the library

Select Publish. Later changes are published the same way. An unpublished library can be cited while you are drafting, but publishing the emails and pages built on it locks in the library version they used.
You’re done when the library shows a published version and its blocks appear with previews.

​
How the check works

An asset composed from a library marks each section with the block it came from. When the asset is saved, allGood checks that every marked section names a real block and still has that block’s shape. It compares structure only — which elements, nested how. It ignores your copy and your styling values, because those are different every time by design. Changing the words in a hero is fine. Changing a hero into something that is no longer a hero is not. A block nested inside another block is checked on its own and is invisible to its parent. So editing a shared button re-checks that button, not every section that contains one.
A failed check names the block and what no longer matches it

A failed check names the block and what no longer matches it.

​
Strict and advisory

Checking is strict by default. A section that does not match its block stops the save, with a message saying which block and what differs. While you are migrating existing content, your team can be moved to warnings instead — either the whole account, or one person at a time, so a marketer mid-migration can keep working while everyone else stays strict.
There is no way to turn checking off entirely, and that is deliberate. A check anyone can disable is a check someone forgets to turn back on. If allGood cannot reach the setting that relaxes it, the answer is strict — a blocked save with a message you can act on is a better failure than an off-brand email that ships.
Ask allGood support to move your account or a specific person to advisory.

​
Good to know

  • No library means no check. With no library declared there is nothing to match against, and the check reports nothing. This is why the second email is the one that benefits — the first one had nothing to conform to.
  • A library is not a template. The library is the vocabulary of blocks; the template is the arrangement of them plus a declaration of what copy changes. Most teams want both.
  • Libraries live under Content, not Templates. The Templates toggle holds shells; a component library is content in its own right.