> ## Documentation Index
> Fetch the complete documentation index at: https://docs.allgoodhq.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Getting started with Content

> Set up your brand, blocks, and layouts once, so every email and page after that is filled in rather than written from scratch.

Content in allGood is two jobs done by two people. Marketing ops decides once how your company's content looks and sounds. A field marketer then makes the individual email, page or form — filling in decisions that were already made, rather than making them again.

Nothing here blocks you. You can write an email on your first day with an empty library, and it will send. The order below matters for a different reason: **each step narrows what the next one has to invent.** Skip the brand step and every email and page you make before it lands will need redoing once it does.

![The Content section, where every screen in this guide lives](https://mintcdn.com/allgoodtechnologyinc/LW4p5NqCb6SZm7Lp/images/mk/content/getting-started-nav.png?fit=max\&auto=format\&n=LW4p5NqCb6SZm7Lp\&q=85\&s=bfc924cd377d15eabbefab322ab4c951)

The Content section, where every screen in this guide lives.

> [!TIP]
>
> If you only need one email or page today, jump to [step 5](#write-the-first-email-or-page). Come back and do steps 1 to 4 before you make the second one.

> [!NOTE]
>
> Every step below uses Workshop (Ask Mary). To use Claude models in it, your account needs an Anthropic API key. To check, open **Integrations** in settings and look for an **Active** badge on the **Anthropic (Claude)** card. See [Add your Anthropic API key](https://docs.allgoodhq.com/mk/integrations/anthropic.md).

## What you'll set up

Steps 1 to 3 are marketing ops, and you do them once. Steps 4 and 5 are the marketer, and they repeat for every campaign.

**1. Capture your brand**

Point allGood at your website and it pulls out your colors, fonts, logos and tone of voice, and saves them as a [**brand guideline**](https://docs.allgoodhq.com/mk/content/brand-guidelines.md). It has versions that you publish, unlike a PDF in a shared drive.

Every generator reads it. The email writer, the page writer, the form writer and both component libraries all take the brand guideline as an input, which is why doing this first is what makes everything after it come out on-brand without being told to.

When you publish something built from it later, allGood locks in the exact version of the brand it was built with. Rebrand a year from now and everything built on the old one shows as out of date, so you can see what needs revisiting instead of guessing.

**You'll have:** one brand guideline.

**2. Publish the blocks**

A [**component library**](https://docs.allgoodhq.com/mk/content/component-libraries.md) is your approved set of building blocks — a hero, a CTA button, a feature row, a footer — each one carrying a note on when it should be used. There are two, because email and web are different craft: an **Email Components** library holds email blocks written in MJML (the email-building language allGood uses), and a **Page Components** library holds web page blocks.

This is the step that does the most work later. Once a library exists, every email and page composed from it is checked against it: each section has to name a real block and still match that block's shape. A generated email cannot quietly wander off the approved set.

The check compares structure only — which elements, nested how. Your copy is different every time and your brand values live in the styling, so neither is ever flagged. Editing a shared button re-checks that button, not every section that contains one.

> [!NOTE]
>
> Checking is strict by default. A section that doesn't match its block stops the save with a message saying which block and what differs. While you're migrating, your team can be switched to warnings instead — either your whole account, or one person at a time. There's no way to turn it off entirely, which is deliberate: a check nobody can disable is one nobody forgets to turn back on.

**You'll have:** an Email Components library, a Page Components library, or both.

**3. Build the layouts**

A [**template**](https://docs.allgoodhq.com/mk/content/templates.md) is a page layout plus a list of what changes. An Email Template is a client-safe email frame; a Landing Page Template is a page layout. Each carries a **copy schema** — the list of what copy the next email or page has to supply. Subject line, headline, body, CTA text.

That declaration is the whole point. Once it exists, making the next email is filling in a named set of fields, not deciding again what an email is.

You can build a template three ways: from a written brief, from a URL of a page you like, or from an email or page you already have in allGood. All three land in the same place.

A template also says which of its parts are rebuilt for each email or page and which are shared. A form is rebuilt, so two pages from one template never accidentally submit to the same place. An image is shared, so your logo isn't copied twenty times.

**You'll have:** an Email Template, a Landing Page Template, or both. They live under the **Templates** toggle in Content, which is the other half of the library — not a filter on the same list.

**4. Hand it over**

A marketer making their first email or page needs to know four things:

1. Which template to start from, if there's more than one.
2. Which component library covers their channel.
3. That component checking is on, and what a failed check looks like.
4. That an email or page goes live only once someone publishes it, and that publishing it also publishes everything it uses. Who on your team does that is your call — what each role is allowed to do is set in [Users and roles](https://docs.allgoodhq.com/ops/users-and-roles.md).

**5. Write the first email or page**

In **Content**, select **Create**. **Email** and **Landing Page** come first, each with the templates you can start from and a **Start from scratch** button. Below them, **More Content** has one tile for each other type, and **Templates** has one for each kind of template. Pick one; you name it and brief it on the next screen.

![Further down Create: a tile for each other type, and for each kind of template](https://mintcdn.com/allgoodtechnologyinc/LW4p5NqCb6SZm7Lp/images/mk/content/getting-started-create.png?fit=max\&auto=format\&n=LW4p5NqCb6SZm7Lp\&q=85\&s=8bd04b36cc3c3a2c10cd6446fa3b83f4)

Further down Create: a tile for each other type, and for each kind of template.

What comes back isn't only the email. Writing an email also produces its [**copy**](https://docs.allgoodhq.com/mk/content/copy-and-variants.md) as a separate document the email cites. That's what lets someone review or rewrite the words without opening the markup, and reuse the same copy on a landing page. If the brief calls for more than one version, you also get a [**content router**](https://docs.allgoodhq.com/mk/content/copy-and-variants.md#variants-and-the-router) — the thing that decides which recipient sees which. Variants come out of writing the email, not out of a separate testing tool.

Then [publish it](https://docs.allgoodhq.com/mk/content/approvals.md). Publishing checks everything it uses and locks each one to the version it was built with, so what goes live is exactly what was reviewed.

You finish with a brand guideline, approved building blocks, templates, and a first email or page built from them.

## What you can make

| | For the marketer | Set up once by ops |
| - | - | - |
| **Email** | Email | Email Template · Email Components |
| **Web** | Landing Page · Form | Landing Page Template · Page Components |
| **Assets** | Visual Asset (images) · Asset (hosted files) | Branding |
| **Words** | Content Document | |
| **Variants** | Content Router | |

## How the pieces fit

Every asset declares what it is built from, and allGood checks those declarations when you save.

* **Cite something you didn't declare** and it's reported as a dangling reference — the most common cause is using a component library without naming it.
* **Declare something nothing uses** and that's reported too, so templates don't accumulate inputs they stopped needing.
* **Ask for something the surface can't provide** and the save is refused. A landing page is built once at publish time, before any particular visitor arrives, so a page asking for a recipient's first name would render empty for everyone. Catching it on save is better than finding it in a screenshot.

This is also what makes publishing trustworthy. Because the declarations are real, publishing an email can check everything it uses and lock every version, and changing a brand or a block can tell you exactly which emails and pages are now out of date.

## Go deeper

> [card] [Publishing and versions](https://docs.allgoodhq.com/mk/content/approvals.md)
>
> What gets locked in when you publish, and how you find out when something an item uses changes.

> [card] [Copy and variants](https://docs.allgoodhq.com/mk/content/copy-and-variants.md)
>
> Why the words are stored separately, and how one campaign sends more than one version.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.