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

# Personalization & dynamic content

> Merge fields, block variants, conditional rendering, and dynamic images for per-recipient content

Denada projects can include per-recipient dynamic content: merge fields, alternate block versions for different audience segments, blocks that only render under certain conditions, and images whose source is supplied by your email service provider (ESP) at send time.

<Note>
  Per-recipient dynamic content is different from [variations](/editor/variations). A variation is a complete parallel version of your project — a translation, say — that you export as its own deliverable. Dynamic content lives inside a single exported email and is resolved by your ESP for each individual recipient.
</Note>

## The library's scripting language

Everything on this page depends on your library having a **scripting language** configured — Liquid or Django-style, matching what your ESP uses (for example, Liquid for Klaviyo or Braze, Django-style for Iterable). The library developer sets this in the library's options.

If no scripting language is set, the dynamic content actions appear disabled in the editor with the note "Requires a scripting language in library options" — without one, Denada has no syntax to emit your ESP's control structures in the exported HTML.

## Merge fields in text

You can type your ESP's expressions directly into text parameters — for example, `{{ first_name }}`. Denada passes the text through untouched, so the expression appears literally in previews and lands intact in the exported HTML for your ESP to resolve at send time.

Links support the same idea: choose the **Dynamic** link type in the **Edit link** dialog to enter merge tags or dynamic URLs without Denada prepending `https://`.

## Block variants

A variant is an alternate version of a block that is chosen per-recipient at send time. Each variant has a name and a **condition** written in the library's scripting language; the first variant whose condition is true renders for that recipient, and the block's main content is the fallback for everyone else.

To add a variant, open the block's **⋯** menu and choose **Add variant**. The **New variant** dialog asks for:

* **Name** — a label like "Platinum".
* **Condition** — the expression that selects this variant, e.g. `person|lookup:'tier' == 'platinum'`.

The variant's content starts as a copy of the block's main content, which you then edit independently — different headline, different image, different link, whatever the segment needs.

Once a block has variants, a switcher pill appears on the block in the preview. Click it to flip between **Main** and each variant so you can preview and edit each version. The Edit tab also lists the block's variants — the **Main** row is the default fallback, and each variant row shows its condition, with a **⋯** menu to **Edit variant…** (name and condition) or **Delete variant**.

## Conditional rendering

Conditional rendering makes a whole block render only when a condition is true — for example, a rewards banner that only gold-tier members should see.

Open the block's **⋯** menu and choose **Conditional rendering**. Enter a condition in the library's scripting language, such as:

```
person|lookup:'tier' == 'gold'
```

Leave the condition blank to always show the block. In the editor preview, a conditionally rendered block is marked with a dashed outline so you can tell it apart — the preview always renders the block's content, and the condition only takes effect in the exported HTML.

<Note>
  A block can have variants or conditional rendering, but not both at once — the block menu offers whichever one is still available.
</Note>

## Dynamic image sources

Sometimes the image itself comes from your ESP — a per-recipient product photo, for instance. Instead of uploading an image, click the image in the preview and choose **Use dynamic source**, then enter an expression like:

```
{{ event.ImageURL }}
```

The expression becomes the image's `src` at send time. See [Using images in projects](/editor/using-images) for the rest of the image menu.

## How this exports to your ESP

You only ever write the *inner* expression — never the surrounding tags. On export, Denada emits the wrapping control structures in your library's scripting language:

* A conditionally rendered block is wrapped in `{% if condition %} … {% endif %}`.
* A block with variants exports as an if/else chain: each variant's condition in order, with the main content as the final else.
* Dynamic image expressions are placed directly into the image's `src` attribute.

Push the exported HTML to your ESP as usual — see [Export formats](/exporting/export-formats) — and your ESP evaluates the conditions per recipient at send time. Because previews render blocks normally, send yourself a proof through your ESP to verify the logic end to end ([Proofs & QA](/exporting/proofs-and-qa)).