Blank Merge Fields: When a Fallback Is the Wrong Fix

A blank merge field is not a formatting problem. It is an incomplete record arriving at the one moment a customer will see it. The standard advice is to set a fallback value, and for a greeting that is correct. For a field the reader has to act on, a fallback is the worst available option, because it turns a message that would have failed loudly into one that reads perfectly and is wrong.

The same blank field produces a different symptom in every tool

One customer record is missing a first name. Depending on where the template gets rendered, that record produces four completely different outcomes, and only one of them is visible without going looking.

Where it renders	What an empty value does	Where a fallback lives
Zapier action step	Treated as though the field was never mapped; a required field errors the task	Formatter Text, Default Value transform, placed before the action
Mailchimp campaign	Renders as nothing, silently	Default merge value, set per audience in audience fields and merge tags
HubSpot marketing email	Renders as blank for that contact	Global default per property type, with a per-email override
JavaScript expression engine (n8n, Make functions, Apps Script)	Prints the literal string undefined into the body	A nullish or logical-or default written into the expression

Zapier documents the first row directly. Its guidance on required-field errors describes a Zap failing on a missing required field even though the field is mapped to a previous step, because the source field was optional and simply carried no value. The mapping exists. The data does not. From the destination app's side, those two situations are identical.

HubSpot documents the second behavior just as plainly: if no default value is set, the token appears blank for that contact. Mailchimp is the same, with an added wrinkle. Default merge values display only in sent emails and never in the audience data, so the audience screen keeps showing you the truth while the campaign shows the customer something else.

The fourth row is the one people search for at 9am after a batch went out. A JavaScript engine converting an absent value to a string produces the characters undefined, and that string goes into the email. It looks like the worst outcome of the four. It is actually the best one, because somebody noticed within the hour.

Three kinds of empty, and the one that slips past your fallback

"Empty" is not one state. There are three, and the fallback you wrote probably only covers two.

The key can be missing from the payload entirely. The key can be present and null. The key can be present and hold an empty string. A CRM that lets a user clear a text box usually stores the third one. An API that omits unset properties gives you the first. A database export gives you the second.

This matters because of a specific and very common mistake. MDN's reference for the nullish coalescing operator states that ?? returns its right-hand operand only when the left side is null or undefined, and contrasts it with ||, which returns the right side for any falsy value. So an expression written as {{ $json.first_name ?? "there" }} looks correct, passes a test with a deliberately deleted field, and then fails in production the day a real record contains an empty string. The operator does exactly what it documents. An empty string is neither null nor undefined, so it passes through and the greeting reads "Hi ,".

The fix is not to memorize which operator to reach for. It is to collapse the three states into one at the boundary, the same way you would normalize an encoding or a phone format before anything downstream touches it. Trim whitespace, convert empty strings to null on ingestion, and every check after that is a single check. This is the same discipline that keeps garbled characters out of customer names: fix the value once, where it enters, not in each of the eleven places it later gets used.

Cosmetic fields get a fallback. Load-bearing fields stop the send.

Here is the rule that almost no guide on this topic states, and it is the whole point.

Sort every merge field in a template into two classes before you decide anything else.

Cosmetic fields are ones where the sentence still means the same thing with a generic substitute. A first name in a greeting. A city in a subject line. A company name in an intro. "Hi Friend" is slightly less warm than "Hi Dana" and costs you nothing. Give these a fallback and move on.

Load-bearing fields are ones the reader has to act on. An appointment date and arrival window. A service address. An invoice number, a balance due, a due date. A technician's name. A tracking link, a portal URL, a callback time. If one of these is blank, the message is not less personal. It is unactionable, or it is wrong.

The test takes five seconds per field. Read the sentence with the value deleted. If it still says something true and complete, the field is cosmetic. If it becomes a question the customer now has to call you to answer, it is load-bearing, and it does not get a fallback.

Consider what a fallback actually does to a real one. "Your technician will arrive Friday between and 2pm" is a phone call. "Your technician will arrive Friday between 8am and 2pm" sent from a record whose real window was Thursday is worse: a missed appointment, a trip-charge argument, a review. A default value of "soon" or "TBD" in that slot does not degrade gracefully either. It ships a confident, specific-looking message built on a record you already knew was broken.

This is where the usual advice inverts. A fallback is a tool for protecting tone. It is not a tool for protecting correctness, and using it that way strips out the only signal that the data needs fixing. Classify the fields in every outbound template in a customer acquisition system before it goes into rotation, because the cost of getting this wrong lands on the customer rather than on a dashboard.

Blocking a send is not the same as dropping it

Stopping the send is only half the job. A blocked message that vanishes is a customer who never got their confirmation, which is its own failure, just a quieter one.

In Zapier, put a filter ahead of the action and require the field to exist. Zapier's required-field guidance names filters and paths as the conditional-logic answer alongside the Formatter default, and the filter is the correct branch when the value is load-bearing. In n8n, an IF node routes the incomplete item to a second branch rather than letting it fall through to the send node.

That branch has to end somewhere a person actually looks. Write the record ID, the template name, and the specific field that was missing to a review table, then work that table daily. Two of those matter most: which record, and which field. Without the second one, someone opens the record, sees a mostly complete customer, and cannot tell what stopped it.

Alert on the rate, not on each event. One blocked send in a batch of four hundred is a data-entry gap and belongs in the queue. Thirty blocked sends is an upstream form or import that stopped populating a column, and that deserves a notification the same hour. Those records belong in the same place as everything else you already capture, which is covered in what to log in every automation.

The pre-send string check that catches the whole class

There is one cheap check that catches every version of this failure, including the ones you did not anticipate, and it belongs in the last step before delivery.

Render the message body, then scan the rendered string for a short deny-list before sending: undefined, null, NaN, [object Object], {{, *|, and None. Any hit means a merge field did not resolve. Add a check for a stranded comma or a doubled space where a value collapsed, which is what catches the silent renderers that leave no telltale string at all.

Run this on the rendered output rather than on the input payload, because then it needs no knowledge of the template. It catches a field somebody added last week and never validated, a nested object that got interpolated whole, and a token misspelled so badly it never matched anything. Six string comparisons on a body you have already assembled cost nothing and cover a class of bugs rather than a list of known ones. Wire it in once as a shared step in your workflow automation layer and every template inherits it.

One more thing, because everybody skips it: test with a deliberately empty record. Teams test personalization against their own contact record, which is always fully populated, and then ship. Keep a permanent test record with a blank first name, no phone, and an empty second address line, and run every new template against it before it goes live.

Where to start

Open your highest-volume outbound template and list every merge field in it. Mark each one cosmetic or load-bearing using the deleted-sentence test. Cosmetic fields get a fallback wherever your platform puts them. Load-bearing fields get a filter or an IF branch in front of the send, plus a review row naming the field that was missing. That is usually a thirty-minute change to one template, and it is the template that would otherwise produce your next apology email.

If you want a second set of eyes on how your outbound messages handle incomplete records, get in touch and we will walk through one of your live templates.