Template variables: personalisation that does not get rejected

You submit a template with two variables, wait, and get it back declined. The sentence was fine. The problem was the twelve characters sitting inside the gap.

I build BNex, a WhatsApp Business Platform product, and most template problems I get asked about are variable problems wearing a wording costume. Meta's reviewer does not read your template the way your customer will. They read the fixed text, plus the sample values you typed into each variable, and they judge that assembled sentence. If the sample value makes the assembled sentence look like an advert, an empty shell, or broken grammar, it gets declined — no matter how good the real data would have been.

Here is what actually goes wrong, and the rules I use before submitting anything.

What a variable is, mechanically

A template is fixed text with numbered gaps. You write "Hi {{1}}, your appointment at {{2}} is confirmed for {{3}}." The template stores the sentence; your system supplies the three values at send time.

Two consequences follow, and almost every mistake comes from missing one of them.

First, at review time the gaps are not empty. They hold whatever sample you submitted. Second, at send time the values are your responsibility — a missing value does not gracefully degrade, it produces a broken message or a failed send depending on how your provider handles it.

Rule one: your sample value is part of the submission

This is the single most common cause of a rejection I see. People submit {{1}} with test, xxx, John Doe, 123, or a sample copied from a tutorial.

Read the assembled sentence as a reviewer would:

Hi test, your appointment at xxx is confirmed for 123.

That does not demonstrate a real transactional message. It demonstrates a placeholder. The reviewer has to guess what the finished message will be, and reviewers decline what they have to guess about.

Put a realistic value in every sample: a plausible first name, a real-looking branch name, a date written the way you will actually write it. The sample is a demo of the finished message. Treat it as copy, because that is what it is.

Rule two: the number of values must match exactly

The second failure is mechanical and it is unforgiving: you defined three variables and your code sends two, or four. Depending on the endpoint you will get a parameter-count error back rather than a silent failure, but it surfaces at send time, which means it surfaces in production at the worst possible moment.

The pattern that causes it is always the same — someone edits the template, adds a fourth gap for the order number, and forgets that the send call is built somewhere else, in a different file, by a different person.

Two habits prevent this. Keep the variable list in one place that both the template and the send code read from, rather than retyping it in two. And after every template edit, send a real one to your own number before switching it live. Not a test in a dashboard — an actual send through the same path your customers use, because the dashboard form does not exercise your code.

Rule three: do not hide the message inside a variable

A variable that carries promotional copy is a variable that turns a utility template into a marketing send in the reviewer's eyes. "Hi {{1}}, {{2}}" where {{2}} contains "50% off ends tonight" is not a personalised update. It is an advert with a name in front of it.

The practical version of this rule: variables carry data, not persuasion. A name, an amount, a date, a reference number, a branch, a tracking link for the specific order. If you find yourself writing a sentence into a variable so you can change it without resubmitting, you have found a way to get declined and, worse, to get reclassified into a higher-cost category. I've written about that cost separately in what each template category actually costs — the label is a price, not a preference.

There is a legitimate need behind that temptation, by the way: wanting to change copy without a new review cycle. That need is real, and variables are the wrong tool for it. Solve it with more templates, not with a variable full of prose.

Rule four: format currency, dates and units in the template, not the value

Put the symbol and the word outside the gap:

Total: ₹{{1}} — not — {{1}}

If {{1}} must supply ₹4,500, then three things can go wrong: some code path sends 4500, some sends 4,500.00, and a locale somewhere sends 4.500,00. All three pass validation and look wrong to the customer. Keep the unit in the fixed text and the number in the variable, and the message stays consistent no matter what calls it.

Same for dates. Write the connective words — "on", "by", "before" — into the template, and decide once, in code, which date format you emit. A date variable that sometimes arrives as 11/11/2026 and sometimes as 11 November is the kind of inconsistency customers notice and reviewers cannot evaluate.

Rule five: plan for the value you will not have

Every field you personalise is a field that will sometimes be empty. A customer with no first name saved. An order with no delivery date yet. A branch that has not been assigned.

If your send code passes an empty string, the message reads "Hi , your order is on its way." That is a small embarrassment at scale. If your code throws instead, the message never sends and nobody finds out until the customer asks.

Decide the fallback deliberately, at the template level, for every variable:

• A default word — "there" for a missing first name is the classic, and it reads fine.
• A restructured sentence — a template that does not require the optional value at all, sent instead of the one that does.
• A hard stop — some variables genuinely cannot be missing, and the correct behaviour is to fail the send, log it, and alert a human.

What you must not do is discover the fallback in production. Put a null through each template once, intentionally, and read what comes out.

The check I run before submitting

Fill every variable with the worst plausible real value, not the best one:

1. The longest name you expect — does the sentence still read naturally?
2. A name with an apostrophe or a non-Latin script — does your encoding survive it?
3. A blank optional field — does the fallback hold?
4. The biggest number you expect — does the currency formatting still look right?

Then read the whole thing out loud. If it sounds like a message a person would receive, submit it. If it sounds like a form letter, the reviewer will reach the same conclusion you just did.

Where this fits

Variables are the last mile of a template workflow: the copy gets approved, the category gets priced, and then the values decide whether the message actually lands as written. The full approval path — wording, categories, and the reasons submissions come back — is in the template approval guide.

If you are running this in more than one language, variable values are also where translations break: the grammar around a gap changes even when the template text is fine. That has its own set of traps, covered in multilingual templates.

BNex builds templates with named rather than positional variables so a missing value is a clear error instead of a shifted sentence. If you want to see how that works on a real account, start a conversation on WhatsApp — I'd rather look at your actual template than answer this in the abstract.

Related Reading