Almost every SFMC email needs it. Order confirmation wants the customer name and order number. Appointment reminder wants the doctor, the time, the room. Bank notification wants the account and balance. Personalization Strings are the simplest way to inject any of those values.
Here's the short version we hand to every dev.
The syntax
Surround the field name with %% anywhere in the email body or subject line:
Subject: %%FirstName%%, your order %%OrderNumber%% is confirmed
Body:
Hi %%FullName%%,
Order %%OrderNumber%% placed at %%OrderTime%% has been confirmed.
It will ship to %%ShippingAddress%% by %%EstimatedDelivery%%.
The field name must match the column name in the sendable Data Extension exactly - not the display label, the actual column name. Case-sensitive.
The Default Value trap
Subscribers with missing data will render:
Hi ,
Order has been confirmed.
The dangling comma and empty order number make the email look like it broke. In some cases it literally did - marketing ops asks why all first-name-less subscribers got a broken email.
Fix the Data Extension, not the email: open the DE, edit each field that's referenced, and set a Default Value.
FirstNamedefault ="there"or a safer "Customer"ShippingAddressdefault ="your address"OrderNumberdefault ="your recent order"
When a field is missing for a subscriber, SFMC uses the Default Value in rendering. The email reads naturally regardless of data completeness.
For edge cases where defaults aren't enough - say "use FirstName if present, else CompanyName, else 'Customer'" - that's AMPscript territory, covered in the next post.
Subject Line only supports Personalization Strings
A recurring mistake: trying to use AMPscript in the subject line.
Subject: %%[SET @name = AttributeValue("FirstName")]%% Hi %%=v(@name)=%%!
Subscribers see that literal string as the email subject. Subject Lines do not render AMPscript. They only process plain Personalization Strings:
Subject: Hi %%FirstName%%!
If you need fallback logic in the subject line ("FirstName if present, else 'Customer'"), move the resolution upstream: pre-compute a GreetingName field in the sendable DE that already has the fallback applied, then use %%GreetingName%% in the subject.
Common fields we personalize
Every engagement ends up using some combination of:
%%FirstName%%- greeting%%FullName%%- more formal greetings%%OrderNumber%%,%%OrderDate%%- transactional receipts%%AppointmentDate%%,%%AppointmentTime%%- healthcare reminders%%Balance%%,%%AccountNumber%%- banking statements%%StoreName%%,%%StoreAddress%%- local-store promotions%%UnsubscribeLink%%- the one required by CAN-SPAM, baked into every email
For the unsubscribe, SFMC also provides %%=RedirectTo(CloudPagesURL(...))=%% patterns when you want to send through a custom Preference Center.
Testing the substitution
Before sending, the Preview & Test > Subscriber Preview view lets you pick an actual subscriber and see the rendered email. Always run this with:
- A subscriber who has every field populated.
- A subscriber missing the optional field (to confirm Default Value kicks in).
- A subscriber with unusual characters in their name (Vietnamese diacritics, O'Brien-style apostrophes).
If all three look clean, you're good to send.
Takeaway
Personalization Strings handle 80% of the personalization asks that land in an SFMC project. Get Default Values right on the Data Extension, keep them out of Subject Lines as AMPscript, and test with multiple subscriber profiles before pressing send. The harder 20% - cross-DE lookups, conditional logic, formatted values - is where AMPscript takes over.
Setting up a personalization stack in SFMC? Our Salesforce team ships production-grade templates with proper Default Values and fallback logic. Get in touch ->
See our full platform services for the stack we cover.
