Personalization and segmentation in Customer Insights - Journeys

Recipient fields (in the body, subject line and preheader) and conditions built in Better Email become Journeys placeholders on the synced email. This page covers how they map. It assumes you have connected Customer Insights - Journeys.

Choose the audience

The integration's Audience setting is the table your journeys address: Contact, Lead or Customer profile (Customer Insights - Data). Recipient field sync reads that table, and profile fields and their conditions bind to it. It also limits trigger fields to triggers that can start a journey for that audience. A journey rejects an email bound to a different table than its own audience.

Changing the audience archives every recipient field synced from the old table; fields added by hand stay. Sync again afterwards, and replace old fields in Campaigns that used them.

Sync recipient fields

1. On the integration, turn on Sync recipient fields and save.
2. Click Sync now.
3. On the Recipient fields tab, turn on Active for the fields marketers may use, and Insertable for the ones they can insert in the Campaign Editor. New fields arrive switched off.

Better Email creates a field for each column that is readable, offered on forms and of a supported type, with the Dataverse logical name filled in. Syncing again is safe: a field you renamed or retyped in Better Email keeps your change, and a column deleted in Dynamics is archived.

Supported column types

Dataverse type	In Better Email
Single Line of Text, Multiple Lines of Text	text
Whole Number	number
Yes/No	boolean
Date Only	date
Choice, up to 100 choices	text, limited to those choices

Left out on purpose, because a mismatched type would quietly target the wrong people: Currency, Decimal and Float; big integers; Date and Time columns with a time of day; lookups; multi-select choices; Status and Status Reason; and choices with more than 100 options. To condition on one of these, use a code segment. For a value from the event that started the journey, see Trigger fields.

Choice columns

Synced choices show by name in the rule builder and send the choice's code to Journeys, so a rule reads Role is Employee and compares 2. Only the choices Dynamics has are allowed. On a field added by hand, enter codes and labels in the Allowed values editor.

Fields added by hand

Set the field's ESP field name to the column's logical name, such as jobtitle or new_loyaltytier, not its display label. You'll find it in Power Apps under Tables › your table › Columns. Otherwise Journeys reports "The binding attribute is invalid or does not exist".

Default values

A text field can have a default value, shown when the record has no value: "Hi Guest" instead of "Hi ". Set it under Default value on the field. In a Campaign, [firstname|there] overrides it for one insertion and [firstname|] turns it off there.

Journeys applies the default at send time, including in the subject line and preheader. The designer shows such a placeholder as, for example, beField_firstname (default: Guest). A default is plain text on one line, up to 100 characters, without ], |, <, >, {, }, ", &, \ or %%. A field with a custom insertion code exports its code as written, without the default.

Customer profiles

With the Customer profile (Customer Insights - Data) audience, Better Email binds to the unified profiles in msdynci_customerprofile, shown in the designer as CustomerProfile › <field>. Three things differ from contacts and leads:

• Column names. Profile columns are msdynci_ plus the source column's name, such as msdynci_firstname, and their labels are the raw source names. Rename the fields in Better Email, and leave technical columns (ids, timestamps) inactive.
• Choices are numbers. The profile table stores a source choice column as a whole number holding the option's code, such as 472100003. It syncs as a number field and conditions compare the code. Keep it a number field, and name it something like Guest tier (code).
• New columns. Click Sync now again after your unification adds columns.

Trigger fields

A trigger field is a value from the event that started the journey rather than from the recipient's profile: a booking's arrival date, the number of guests, or the name of the hotel the booking is for. Marketers insert it from the field picker, with no code and no access to Dynamics.

Journeys only fills in a trigger field when the journey was started by that trigger. An email written for "Booking created" can't show an arrival date in a journey started by "Newsletter signup". So a Campaign records which trigger it is written for, and Better Email checks the fields against it.

Sync triggers

Sync recipient fields also reads the triggers in your environment that can start a journey for the integration's audience: your custom triggers, such as a Booking created trigger your team built, and Dynamics' business-event triggers. Interaction triggers such as Email opened and Email delivered are left out.

Better Email offers the attributes the Journeys designer lists under a trigger, where the type is supported:

• Values on the trigger, such as Booking created › Arrival date or the date and time the trigger fired. Text, whole numbers, yes/no and dates with or without a time come through.
• Values on a record the trigger points to, one step away. A trigger that refers to a hotel record gives fields such as Booking created › Hotel › Name. These follow the column types of profile fields, except choices. The sync brings them in for your custom triggers. Dynamics' own triggers point at large standard tables such as Event and Contact, so for those, add the values you need by hand.

The recipient and source-system attributes every trigger carries are left out. As with profile fields, new trigger fields arrive switched off:

1. Click Sync now on the integration.
2. On the Recipient fields tab, find the trigger's fields and turn on Active and Insertable for the ones marketers should use. Rename them freely; the binding to the trigger doesn't change.

A trigger created in Dynamics after the last sync shows up at the next Sync now. You can also add a field by hand: create a field, choose the trigger, then the attribute, or a record it points to and that record's column. The lists come straight from Dynamics, so they include triggers created since the last sync. A trigger or attribute deleted in Dynamics is archived on the next sync.

The display names come from Dynamics in the environment's language, so you may want to rename fields into the language your marketers work in.

Set the trigger on the Campaign

Set Journey trigger in the Campaign's settings. On a Campaign type whose Destination is a Journeys integration, set it once on the type, and every Campaign created from it starts with that trigger. A "Booking confirmation" type then always means the booking trigger, and marketers don't have to pick it. They can still change it in the Campaign's settings.

With a trigger set, the Campaign Editor offers that trigger's fields next to the profile fields. Fields from other triggers aren't offered.

Use trigger fields

Insert trigger fields in the body, subject line and preheader, give text trigger fields a default value, and give them sample values in preview profiles.

Conditions work on trigger fields too, so a Block can show one variant for arrivals before 1 June and another for the rest.

One email can mix profile fields and trigger fields, in its content and in its conditions. In the Journeys designer, once an email has profile personalization, the field picker hides the trigger until you reset the email.

Before a sync, a pre-flight check fails if the Campaign uses a trigger field and has no Journey trigger, or uses a field from a different trigger than the one set. Fix it by setting the trigger, or by replacing the field.

On sync, Better Email binds each trigger field to the trigger's data on the Journeys email. Use the email in journeys that start with that trigger.

For a list of related records, such as a guest's upcoming bookings, see Advanced: Journeys tokens.

Segmentation

Conditions built in Better Email become Journeys conditions on the email, and the body switches between variants as it does in the editor. All six operators work (is, is not, greater than, less than, is set, is not set), with AND/OR groups, nesting and negation. Variants keep their order, and Everybody else is the last branch.

In the Journeys designer, conditions are toggled true or false by hand rather than following the sample record. To check rules against realistic data, use preview profiles in Better Email.

Code segments

A code saved segment for this integration is the name of one condition you maintain in the Journeys designer, such as VipCustomers. Journeys only accepts a placeholder name there, so other ESPs' snippets don't apply.

Better Email can't see inside that condition, so it can't share a group with other rules. For "VIP and in Germany", add the country test to the condition in Journeys, or build the whole rule from recipient fields. A sync that mixes the two fails rather than sending to a wider audience.

Define the condition in the designer after the first sync. Later syncs keep it as long as the email uses the name.

Related docs

• Customer Insights - Journeys integration
• Recipient Fields / Merge Tags
• Dynamic Content / Segmentation