Skip to main content

Global settings & Global Script

The Global setting is a special, pinned setting on every template base. It is the place to put values that should be available across the entire email — in the template base, in every module, and even in things like color palettes — without having to thread them through component settings.

It comes in two parts:

  • Global inputs — fields you define inside the Global setting, exactly like any other input
  • Global Script — a small Liquid script that can read those inputs (and a few runtime values) and produce computed values

Everything the Global setting exposes lives under the global.* namespace.

When to use the Global setting​

Use the Global setting for values that:

  • belong to the whole email, not to one module (brand, language, market, theme)
  • need to be referenced from several modules without copy-pasting
  • depend on other values and should be calculated once, not in every module
  • should be derived from the selected integration when an email is exported

Typical examples:

  • a brand or business unit selector that drives colors, logos, and footer text
  • a market or language switch that swaps copy, links, or compliance blocks
  • a primary/accent color pair derived from a brand selection
  • a feature toggle that several modules react to

If a value only matters for one module, keep it as a normal module setting instead.

Global inputs​

Global inputs are added the same way as any other setting input. The only difference is the namespace: instead of template.brand.color, they are referenced as global.color.

Use Global inputs whenever you want a marketer-editable field that is the same value across the whole email.

<a href="{{ link.url }}" style="background:{{ global.primary_color }};">
  {{ button.label }}
</a>

TODO: Add a screenshot of the Global setting pinned at the top of the template base settings panel with a few inputs configured.

The Global Script​

The Global Script is a small Liquid program that runs once before the rest of the email is rendered — it is the first stage of the rendering pipeline. It is the right place to:

  • compute derived values from Global inputs
  • branch on the selected integration to apply per-BU branding
  • normalize values that should be consistent across modules

It does not output text. It only exports values. Use the {% set_global %} tag for every value you want to expose to the rest of the template.

{% set_global brand_color = "#0044CC" %}
{% set_global font_stack = "'Inter', Arial, sans-serif" %}

After the script runs, those values are available everywhere as global.brand_color and global.font_stack.

Reading inputs in the script​

Inside the script, all Global inputs are available under global.* as raw values. You can read them, transform them, and re-export them:

{% if global.brand == "north" %}
  {% set_global primary_color = "#003366" %}
  {% set_global logo_url = "https://cdn.example.com/north/logo.png" %}
{% elsif global.brand == "south" %}
  {% set_global primary_color = "#A8161D" %}
  {% set_global logo_url = "https://cdn.example.com/south/logo.png" %}
{% endif %}

If a set_global value uses the same key as a Global input, the computed value wins downstream. That makes it safe to use the script to "promote" raw inputs into final values.

Runtime values: the render context​

The script can read the render context: context.isPreview and context.integration are always available inside the Global Script, and while an email is rendering so is context.email.moduleKeys — the module keys of the blocks in the email. The rest is out of reach by construction: context.email.subject and context.email.preheader are null because they render after (and using) the script's output, and context.block is null because the script runs once, not per block.

When there is no email at all — the Template Editor's calculated-values panel and module previews — context.email is null entirely, so guard email-dependent logic with {% if context.email %}. For example, requiring the footer to show offer terms whenever the promo module is used anywhere in the email:

{% if context.email and context.email.moduleKeys contains "promo_offer" %}
  {% set_global show_offer_terms = true %}
{% else %}
  {% set_global show_offer_terms = false %}
{% endif %}

Note that the calculated-values panel shows the no-email branch of such scripts; the real value is only visible in an email preview.

This is what makes the Global Script especially useful in multi-BU setups: you can branch on the integration the marketer is exporting to, and apply per-BU branding without exposing a brand selector at all.

{% if context.integration.id == 1 %}
  {% set_global primary_color = "#FFF333" %}
  {% set_global logo_url = "https://cdn.example.com/bu-a/logo.png" %}
{% elsif context.integration.id == 2 %}
  {% set_global primary_color = "#0044CC" %}
  {% set_global logo_url = "https://cdn.example.com/bu-b/logo.png" %}
{% endif %}

Combined with groups and access control, each business unit only sees its own integration, so the right branding is selected automatically.

You can also use context.integration.id in a module's Only show if condition. This is useful when a module should only be available for emails connected to a specific integration.

Legacy: global.integrationId

Older templates branch on global.integrationId, which is still injected automatically and keeps working. New templates should use context.integration.id — same value, and it keeps global.* reserved for values you define.

TODO: Add a screenshot of the Global Script editor with a multi-integration if/elsif block and the calculated outputs panel below it.

Inspecting calculated values​

The Template Editor shows the effective Global namespace below the Global setting. It includes:

  • the current default value of every Global input
  • the currently selected integration ID (you can switch it from a dropdown)
  • every key produced by {% set_global %}

Use this to check that the script behaves the way you expect before opening preview.

Autocomplete and references​

Anywhere you write Liquid in the template — template base, modules, color palettes — you can reference Global values as global.*. Both raw inputs and computed outputs are exposed, and both show up in autocomplete in the code editor.

Using global values in input authoring fields​

Most authoring fields in the input editor — hint, placeholder, select option name and value, color option value — support an FX mode that turns the field into a Liquid expression. This is the easiest way to make modules follow global values without writing any module-level Liquid.

For example, on a button module's color picker, set the swatch values to global.primary_color and global.secondary_color in FX mode. The marketer sees real, brand-correct colors in the swatch list, and changing the brand mapping in the Global Script updates every module's palette automatically.

FX mode is intentionally not available inside the Global setting itself — Global inputs feed the global.* namespace, so referencing it from within would be circular. Compute derived values in the Global Script instead.

Best practices​

  • Use Global inputs for the small set of values that are truly cross-cutting; don't make global inputs just because they could be reused.
  • Compute derived values once in the Global Script instead of repeating the same if/assign blocks in every module.
  • Prefer context.integration.id branching when access control already locks each team to their own integration; it removes the need for a manual brand selector.
  • Use computed Global flags when module availability depends on more than one value, then reference the flag from the module's Only show if condition.
  • Keep set_global keys short and stable — modules will reference them.
  • Use the calculated outputs panel to verify the script before testing in preview.