Email personalisation and dynamic text

What it does

Dynamic text drops record values into a message at send time — a first name, an order number, an event date. You build tokens against a data binding, give them a label and a default value, and either use them once or publish them to a shared predefined list that every author can pick from.

Key facts

Every piece of dynamic text is three things: a data binding (where the value comes from), a label (what authors see and type), and a default value (what renders when the source is empty). Skip the default and you ship "Hi ," to somebody.
Data sources are offered as Audience, Trigger and Compliance. Audience gets you the contact or lead and anything related to it; Trigger gets you the payload of the trigger that started the journey; Compliance gets you preference centre and unsubscribe links.
You can walk relationships, including 1:N and N:N. For a 1:N you define a condition to pick which related record to use; where the condition still matches several, the most recently created record wins.
Beyond the audience, the Other tables picker exposes other Dataverse tables. That list is capped at 50 tables and is curated through Manage list.
Where Customer Insights - Data is connected, calculated measures show up as usable values. They're single-dimension only — one value back per profile.
The predefined list surfaces the ten most-used tokens across the organisation first, then the rest alphabetically. You publish to it with Save & add to predefined list from the dropdown next to Save.
Once a token is on the predefined list, only its default value can be edited globally. Changing the underlying binding means deleting it and recreating it.
Global changes apply to the current message and future usage. They do not reach back into messages already built with that token.
Power Fx transforms sit behind the Advanced section — tick Power Fx formula and write against the token's display name (single-quote it if it contains spaces). Limits: 500 characters, five levels of nesting, one dynamic text value per formula. Table functions like Filter(), Sort() and GroupBy() aren't supported, nor are custom functions.
Option sets aren't supported in dynamic text. They do work in conditions, and inline conditions can output the option's value into the message — that's the workaround.
Personalisation tokens are scoped to the business unit they were created in. Multi-brand tenants recreate them per business unit.

When to use / skip

Everyone wants personalisation and most of it should stop at name, company and a couple of transactional fields. The value is in the transactional stuff — an order reference, a renewal date, a session time — because that's what makes the email feel like it came from a system that knows the customer rather than a mailing list.

Where I'd hold back is deep relationship traversal. Three hops through related tables to pull a value is a query that runs at send time for every recipient, and a data model change eighteen months later will break it silently. If the value matters that much, get it onto the audience record or into the trigger payload.

Power Fx is worth reaching for when a locale-correct date or currency is needed, or when you want a clean Coalesce() fallback. It is not worth reaching for as a general-purpose transformation layer.

Configuration decisions

Which tokens are curated onto the predefined list and who owns that list. Left open, you get four variants of "First name" with different defaults.
The default value for every token, agreed with the client in their tone of voice — "there" and "customer" read very differently.
Whether personalisation is driven from the audience record or from the trigger payload. Trigger-driven personalisation is more accurate but constrains where the message can be used.
Which of the 50 Other tables slots you actually need, and whether the value should instead be denormalised onto the contact.
Whether to allow Prevent HTML encoding on any token. It exists for injecting markup from a trusted source and it is an injection risk anywhere else.
Whether locale formatting is handled with Power Fx per token or by storing pre-formatted values upstream.

Gotchas

A message that personalises from trigger data can only be used in journeys started by that trigger. Drop it into a mid-journey step and you get an error, usually after the journey has been designed around it.
Power Fx failures are silent. A syntax or type error doesn't block the send — the message goes out with the original or default value instead. Nobody finds out unless they're reading the output.
Tokens don't cross business units. Multi-brand or multi-country rollouts discover this after building the whole token library in one BU.
Where the audience record's owner sits affects what personalisation can resolve — record ownership and business unit scoping apply at send time, not at design time.
Using Other tables requires a specific record to be selected before the message can be marked ready to send. Authors read this as a bug.
Updating a predefined token doesn't retrofit existing emails, so the "we changed it centrally" assurance is only true for content built afterwards.

Consultant notes

Demo a broken token with and without a default value. It takes thirty seconds and it stops the argument about whether defaults are optional.
Build the token library as a deliverable with named owners, not as a by-product of the first campaign build.
Before go-live, preview with sample data that includes nulls and awkward values — long company names, missing surnames, an apostrophe — not just the tidy test contact.
Push back on personalising the subject line with anything that can be empty unless the default reads naturally on its own.
If the client is coming from an ESP with a scripting language, set expectations early: this is token substitution plus limited Power Fx, not a templating engine.

Worth another look if Power Fx support widens beyond single-value transforms, or if option set handling in dynamic text changes.