Skip to content

Variables

Variables are the foundation of personalized templates. They let you pull in real data about your contacts, events, and more -- so every email feels like it was written just for the recipient. Every NLT expression is wrapped in curly braces { }.


Three Data Sources

NLT can pull data from three places. The syntax you use tells the engine where to look.

Tip

Smart quotes are handled automatically. If you paste template text from Google Docs, Word, or macOS Notes, curly/smart apostrophes like \u2019 are automatically converted to the correct straight apostrophe '. You don't need to worry about which apostrophe character you use — NLT handles it for you.

1. Contact Data (the user's ...)

Access any field or property stored on the contact profile:

Example: Contact field

Template:

{the user's First Name}

Output:

Jane

Example: Another contact field

Template:

{the user's Email}

Output:

[email protected]

You can access any contact property this way -- plan, phone number, subscription status, or any custom field your team has set up:

{the user's First Name}
{the user's Email}
{the user's Phone}
{the user's Subscription Status}

2. Trigger Event Data (the ... from the trigger event)

When an email is triggered by an event (like a purchase or signup), you can pull data from that event:

Example: Trigger event attribute

Template:

{the Order ID from the trigger event}

Output:

ORD-4821

Example: Another trigger event attribute

Template:

{the Amount from the trigger event}

Output:

99.99

{the Reference Number from the trigger event}
{the Order ID from the trigger event}
{the Amount from the trigger event}

3. Named Event Data (the ... from the ... event)

Access data from a specific type of event by name:

Example: Named event attribute

Template:

{the Amount from the payment event}

Output:

150.00

Example: Another named event

Template:

{the Policy Number from the self_buy event}

Output:

POL-7890

{the Amount from the payment event}
{the Policy Number from the self_buy event}
{the Amount from the latest payment event}
Tip

The word latest is optional -- {the Amount from the payment event} and {the Amount from the latest payment event} do exactly the same thing.


Nested Properties (Dot Notation)

Contact data is often structured with nested fields. Use dot notation to reach into nested objects:

Example: Nested object access

Template:

{the user's Address.City}

Output:

New York

Example: Deeper nesting

Template:

{the user's Preferences.Theme}

Output:

dark

You can also access items in a list by their position (starting from 0):

Example: Array index access

Template:

{the user's Orders.0.Name}

Output:

Widget Pro

{the user's Address.City}
{the user's Address.State}
{the user's Preferences.Theme}
{the user's Orders.0.Name}
{the user's Orders.0.Price}
Note

Array indices start at 0, so .0 is the first item, .1 is the second, and so on.


Fallback Values

Sometimes a contact won't have a particular field filled in. Use or to provide a friendly fallback:

Example: Fallback when First Name is missing

Template:

{the user's First Name, or "Customer"}

Output:

Customer

Example: Fallback in a greeting

Template:

Hi {the user's First Name, or "there"}!

Output:

Hi there!

{the user's First Name, or "Customer"}
{the user's City, or "your city"}
{the user's Phone, or "not provided"}
Tip

The or fallback only kicks in when the value is truly missing (null). If the field exists but is an empty string or zero, the original value is kept. If you want to replace empty strings and zero too, use the default filter instead -- see the Filters page.


Required Fields (Send Suppression)

For critical transactional emails, you might need to guarantee that certain data is present. The required modifier prevents the email from sending at all if the value is missing:

Example: Required modifier

Template:

{the Reference Number from the trigger event, required}

Output:

REF-001 (or email is suppressed if missing)

{the Reference Number from the trigger event, required}

If the Reference Number is null, the entire email (both subject and body) is suppressed. The system logs the reason: "Required attribute 'Reference Number' is missing".

Warning

Use required carefully -- it stops the entire email from sending. This is intended for transactional emails where sending with blank critical data (like a policy number or order ID) would be worse than not sending at all.


Unfilled Placeholders

When you insert a suggestion that needs a value, the editor may show a «…» placeholder — for example «first_name» — that you finish filling in. A «…» is not a variable: it is a "fill me" marker. If one is left in your subject or body, Synapse will not send the message (it would otherwise arrive as literal «first_name» text). The send is recorded as failed — across email, SMS, and WhatsApp — and the validation panel flags a blocking error until you fill it.

This is different from a required field: a missing required value suppresses the send (a deliberate skip you asked for), while a leftover «…» fails the send (a mistake to fix). To fill a placeholder, click it in the editor and pick a value; it becomes a real {the user's ...} variable.


Combining It All Together

You can combine variables from different sources, with fallbacks and formatting, in a single template:

Example: Multiple variables in one template

Template:

Hi {the user's First Name, or "there"}! Your order {the Order ID from the trigger event} for {the Amount from the trigger event, as "currency"} has been confirmed.

Output:

Hi Jane! Your order ORD-4821 for $99.99 has been confirmed.

Tip

You can use as many variables as you need in a single template. Mix and match contact data, event data, and named events freely.