Use the condition option to conditionally show or hide email blocks based on personal data.
Tabular's condition option can be used to conditionally show or hide email blocks based on personal client data. In the condition option settings you specify the opening and closing markup for if statements.
You can include conditional logic in your email templates by using if statements or unless statements. To be able to use if statements, your email service provider should offer a templating language with if statement support.
The idea is that the block that you wish to conditionally show or hide should be wrapped in an if statement. Wrapping a block, means that before the block we add an opening expression, and after the block we add a closing expression.
In the opening expression of the if statement you add a condition, and only if the condition evaluates to true, the block will be visible.
The templating language used differs per email service provider, but for example the HTML when using the Handlebars templating language, would look like the following:
{{#if isMember}}
<h1>{{firstName}} {{lastName}}</h1>
{{/if}}
When you have the following client data:
{
isMember: true,
firstName: "Yehuda",
lastName: "Katz",
}
Would resolve to the following HTML, when the email service provider substitutes the if statement and the variables with the provided values:
<h1>Yehuda Katz</h1>
{% if condition %}
, where condition should be replaced with the boolean rule that will be evaluated as being true or false. With the Handlebars language it would look like: {{#if condition}}
.{% endif %}
. With the Handlebars language it would look like: {{/if}}
.Using HubSpot's HubL language, in Tabular this would then look like:
Using the Handlebars templating language, in Tabular this would then look like:
Each uniquely personalized email will need to be automatically generated and during this the if-else variables will be substituted with client data.
This process of substituting the variables with the client data is typically performed by your email service provider (ESP). Your ESP should then also have access to that client data.
Some ESPs may offer functionalities to manually add the client data or they might collect the client data. Other ESPs may offer integrations, so that you can connect the database where you've stored the client data, with the ESP, so that the ESP can fetch the client data from your database. If you programmatically send emails using the ESP's API, most API's offer endpoints that you can use to send variable values to the ESP.
Another option if you have developers in your team, is to do this process of substitution on your own backend server, and then sending the HTML using the API of an ESP.
Most email service providers offer a templating language, see the following table that lists the most commonly used ESPs and if they offer if-else support:
Email service provider | Link to documentation | If statement support |
---|---|---|
HubSpot | HubL Templating Language | ✅ HubSpot If statement |
Mailchimp | Merge tags | ✅ Conditional merge tags |
Mailchimp Transactional | Handlebars and Merge Tags | ✅ The if helper |
Postmark | Mustachio | ✅ Scoping |
Crisp | Handlebars | ✅ #if |
Mailgun | Handlebars | ✅ #if |
Brevo | Handlebars | ✅ #if |
Klaviyo | Conditional logic | ✅ #if |
SendGrid | Using Handlebars | ✅ #if |
MailerLite | Variables in MailerLite | ❓ No documentation |
Mailjet | Mailjet Templating Language | ✅ If-conditional statements |
Auth0 | Using Liquid Syntax | ✅ If-else |
Moosend | ❌ No support | ❌ No support |
VBOUT | ❓ No documentation | ❓ No documentation |
ZeptoMail | Dynamic Templates) | ✅ Conditional statement |
SendPulse | Clever personalization | ✅ Examples |
Acumbamail | ❓ No documentation | ❓ No documentation |
Sendy | ❓ No documentation | ❓ No documentation |
Transpond | Merge Tags | ✅ Conditional merge tags |
Encharge | Personalization with Liquid | ✅ If-else |