Skip to main content

Modules

Modules are the reusable content blocks marketers add to emails. A strong module is easy to recognize, easy to configure, and flexible enough to cover a real content need without becoming messy.

Each module usually contains:

  • HTML and Liquid code
  • settings and inputs
  • metadata such as thumbnail, hidden status, and AI context

What makes a good module​

A good module should have one clear job. For example:

  • hero
  • article card
  • promo banner
  • image with text
  • product row

If a module is trying to do everything, it usually becomes hard to use in the Email Editor.

Creating modules​

You can create a module in the Template Editor by:

  • adding a new blank module
  • extracting an existing section of code from the template base into a module

The extraction workflow is especially useful when you start from a finished HTML email and want to turn it into a reusable system.

TODO: Add a screenshot or short video showing a section of base HTML being extracted into a new module.

Settings​

Each module has its own settings. These settings are what marketers edit when they select the module in the Email Editor.

Read more:

Metadata​

Metadata improves how the module behaves and how easy it is to manage.

Thumbnail​

The thumbnail helps marketers recognize the module quickly in the module list. Use a realistic example state, not a blank placeholder.

Hidden status​

Hidden modules stay in the template but do not appear in the marketer-facing module list. This is useful when you want to retire a module without deleting its code immediately.

Conditional module visibility​

Use Only show if when a module should be available only in some email contexts. The condition is checked against the email's current Global values — including values produced by the Global Script — and context.integration.id from the render context.

For example, a module can be available only for one business unit:

global.business_unit == 'retail'

Or only when the email uses a specific integration:

context.integration.id == 481

You can also use a Global Script to compute a simpler flag and use that in the module condition:

global.allow_hero_module == true

Module conditions can reference global.* values and context.integration.id (checking context.integration against null also works). The rest of the render context is not available here — and conditions referencing it are rejected when you save: context.email and context.block because visibility is decided before the email renders, context.isPreview because what's visible must agree between preview and export, and context.integration.name/.type because the integration id is the only field editor-side checks can reconstruct. If the condition evaluates to false, the module is hidden from the module list in the Email Editor and from Betty's available module list for that email.

This only controls whether the module can be added from that point forward. If a module has already been added to an email, it stays in the email even if the template later gets a condition that would hide it from the module list.

In the Template Editor preview, a selected module with a non-matching condition is still rendered with an overlay. This lets template authors check the module layout while also seeing that marketers would not be able to add it in the current context.

Content-zone restrictions​

If the template has more than one content zone, each module can be restricted to the zones it actually fits in. Restrictions apply everywhere a module can be added or moved — the module sidebar, drag-and-drop, and Betty.

By default, a module is only allowed in the Main zone. Open another zone for a module only when it makes sense visually and structurally.

See Content zones for more details.

AI metadata​

AI metadata helps Betty understand how the module should be used, what kind of content it is for, and any important rules it should follow.

TODO: Add a screenshot of the Metadata tab showing module name, hidden toggle, thumbnail, and AI metadata.

  • Keep module names short and specific.
  • Give every production module a useful thumbnail.
  • Hide modules before deleting them when you are unsure whether they are still needed.
  • Use conditional module visibility for business-unit, market, integration, or feature-flag differences that should affect which modules marketers can add.
  • Use repeatable settings when one module needs a repeatable content structure.