An email can change depending on who receives it — greet people by name, show a paragraph only to donors, say something different to people whose first name you do not have. There are three ways to do it, and they are the same feature at three levels of effort. Start at the top and only go further down if you need to.
A fallback on a single value — one word changes.
A display condition on a row — a whole row appears or disappears. No typing.
A condition you write yourself — anything else, including comparing a field against a value.
They are one syntax, not three features. The display-condition menu in step 2 writes the same {% if %} code that step 3 has you type by hand. Learning step 3 is learning what the menu was doing for you all along.
Where each of these works
Campaign emails | Automated emails | Landing pages | |
Merge tags and fallbacks | Yes | Yes | No |
Row display conditions | Yes | Yes — except the double opt-in email | No |
Conditions you write yourself | Yes | Yes | No |
Campaign emails and automated emails are rendered in different places, so automated emails support a deliberate subset of the syntax — everything on this page works in both. Landing pages support none of it: a page is built once and shown to every visitor, so there is nobody to personalize it for.
To personalize what someone sees on a page, link to it from an email and let the email pass what the page needs. For a link to one of your own CamBuildr pages, that is the prefill link:
https://your-page.org/sign?{{ var:prefill_link }}The page then greets the recipient by name and shows their address masked, with a That's not me option — without the address travelling in the URL. To pre-fill other fields, add them as named parameters (?{{ var:prefill_link }}&zip={{ var:zip }}). Putting a person's own data into a link address still works but now raises a warning when you save, because anything in a URL is readable by the target site, its analytics and its server logs. Prefilling Forms in Apps covers both routes.
1. A fallback for a single value
The simplest case, and the one most people actually want: use the value when you have it, and a sensible word when you do not. Add the fallback after a second colon.
Hello {{ var:firstname:there }},That prints Hello Anna, for Anna and Hello there, for someone whose first name you never captured. It works anywhere a merge tag works: body text, the subject line, the preheader and link addresses.
The Available placeholders window in the editor lists every field this email can use, together with the syntax. For an automated email the list depends on the trigger you chose — a donation trigger adds the amount and the purpose, an event trigger adds the event name and date.
2. Show or hide a whole row: display conditions
When the difference is more than a word, put the two versions on two rows and let CamBuildr choose between them. Select a row and open Display Conditions in the sidebar.
Fields are grouped under Person data, Custom fields and — for automated emails — Action data, the fields belonging to the action that triggered the email. Each field appears twice, so searching for first name gives you both:
First name is set — the row is shown only to people who have one.
First name is missing — the row is shown only to people who do not.
Put one on each of two rows and you have a personal greeting and a generic one, without typing anything. The two are separate conditions rather than two halves of one, so you can move or delete either row and the other still behaves.
What the menu is actually writing. Choosing First name is set wraps that row in exactly this:
{% if var:firstname:false %}
… the row …
{% endif %}Which is the same syntax as step 3 below — and also why a display condition can only ask whether a field is filled in or empty. To compare a field against a particular value, carry on to step 3.
3. Writing the condition yourself
Anything the menu cannot express, you can write. There are two places to put it:
As a custom display condition — in the Display Conditions dialog, instead of picking from the list, enter the condition yourself. It still wraps the selected row.
As text inside a block — type it straight into a text or HTML block, around the words it should govern. Use this when the difference is a sentence rather than a row.
This is where comparing a value becomes possible:
{% if var:country_code == "AT" %}
Text for Austria
{% elseif var:country_code == "DE" %}
Text for Germany
{% else %}
Text for everyone else
{% endif %}Available: {% if %}, {% elseif %}, {% else %}, {% endif %}; the comparisons == != < > <= >=; and, or, not; and Upper(), Lower(), Capitalize() around a field. Every {% if %} needs its own {% endif %} in the same block of text.
Not available in automated emails: loops ({% for %}), variable assignment ({% set %}), arithmetic, and the data:, segment: and mj: field families. Write one of these and the editor shows a warning when you save; the construct is removed before the email goes out, so it never reaches a recipient as raw text.
Reusing what you built. Rather than typing a greeting into every email, save the row: select it, save it as a row, and find it again under Rows > Saved Rows. Putting it into your templates works too.
A test email shows every version
Test sends fill every field with sample data, so both sides of a condition appear in the test email. That is expected, and campaign email test sends have always behaved this way. To see what one particular person receives, send the real email to a target audience containing only them. The same applies to the prefill link: a test send carries a dummy token, so the recognition card only appears on a real send.
Tags cannot be used as a condition
Whether a person carries a certain tag cannot be checked inside the email itself: tags are available neither as merge tags nor as display conditions. There are two ways to get the same result:
Build a target audience with the filter The person has the tag and send a separate campaign email per tag.
Build a workflow with Condition steps. A condition always splits into exactly two paths, yes and no, so for five tags you need four conditions chained one after the other.