Running segments off Dataverse or off Customer Insights

What it does

Real-time journeys can target three entities: the Dataverse Contact, the Dataverse Lead, and the Customer profile produced by Customer Insights – Data. You choose which under Settings > Customer engagement > Audience configuration, and that choice decides where segments are built, what personalisation can reach, and how much of the programme depends on a data unification pipeline running on time.

Key facts

Audience configuration is where recipient fields are set per entity. Contact and Lead ship with default email and phone fields already mapped. Customer profile has no defaults — you set them yourself, or nothing sends.
From the February 2024 release onwards, multiple email addresses can be configured for a contact's email channel. Before that it was one address per contact.
Customer Insights – Data is discovered automatically if it is set up before Journeys is provisioned. If Journeys came first, connect it manually at Settings > Data management > Customer Insights – Data connector and choose Connect.
The Data side needs work before it is usable: data sharing enabled between Customer Insights – Data and the Dataverse org via Advanced settings, Map, Match and Merge rules configured, and at least one segment created.
Both environments must sit in a region where Customer Insights – Journeys is available.
Once connected, Customer Insights – Data segments appear in the journey Audience dropdown alongside Journeys segments, and unified profile attributes become available for personalisation in email, SMS and push.
Custom triggers can carry a Customer Data property with Data type set to Profile (Customer Insights – Data), which is how a trigger-based journey resolves to a unified profile rather than a contact.
Licensing meters the two independently: Journeys consumes Interacted People, Data consumes Unified People. Base entitlements are 10,000 and 100,000 respectively, tenant-wide.
A single journey cannot mix contacts and leads.

When to use / skip

Default: Dataverse contacts. On the large majority of UK mid-market Dynamics implementations, the contact record is already the operational truth, the segment builder over Dataverse is quick, marketing can self-serve, and there is no unification pipeline to go wrong at three in the morning before a send. Start there and stay there unless something forces the issue.

Bring Customer Insights – Data in when the client genuinely has customer data outside Dataverse that matters to targeting — an ecommerce platform, a loyalty system, a booking engine, a core banking or policy system — and when duplicate identities across those sources are a real problem rather than a theoretical one. The unification is the product. If all the data is already in Dataverse, Customer Insights – Data mostly adds a refresh schedule, a second licence meter and a second place to debug.

The thing that decides it in practice is usually behavioural data. If segmentation needs "bought in the last 90 days" or "abandoned three baskets", and that lives in a warehouse, Dataverse alone will not get you there without an ingestion project of its own — at which point Customer Insights – Data is the supported ingestion project.

Where I would go against the default: a B2C client with a serious identity problem — same person as four records across web, store and call centre — should start with Customer Insights – Data even if it delays phase one, because segmenting on unmerged duplicates produces sends that embarrass the client. Conversely, a B2B client with 40,000 contacts, clean account hierarchies and everything in Dynamics does not need it, whatever the account team suggested.

If you are running both, be deliberate. Journeys segments and Customer Insights – Data segments both appear in the same dropdown, and a marketer cannot tell from the picker which one refreshes on a schedule and which is live. Name them so they can.

Configuration decisions

Which entities are enabled as audience sources, and which fields carry email and phone for each. Customer profile has no defaults, so this is mandatory work if you use it.
Whether leads are targeted at all. Enabling them means separate journeys, because contacts and leads cannot share one.
Whether multiple email addresses per contact are configured, and which address consent is recorded against.
Where segment building happens day to day — Journeys segment builder, Customer Insights – Data, or both — and who owns each.
Refresh cadence on the Customer Insights – Data side, and how it lines up with journey schedules and quiet times.
For trigger-based journeys, whether the trigger's customer data resolves to a contact or to a unified profile.

Gotchas

Customer profile audiences send nothing until you set the default email and phone attributes yourself. There is no fallback, and the failure looks like a journey that ran with zero recipients.
Provisioning order matters. Journeys provisioned before Customer Insights – Data will not discover it, and people spend a while looking for a setting that only appears after a manual Connect.
Consent is stored against the contact point, which is entity-agnostic and therefore shared. A unified profile and a contact resolving to the same email address share one consent record — usually what you want, occasionally a surprise.
Segments sourced from Customer Insights – Data are only as fresh as the last refresh. A journey scheduled shortly after a failed refresh targets yesterday's population without saying so.

Consultant notes

Ask early where the data that drives segmentation actually lives. If the answer is "Dynamics", say so plainly and keep Customer Insights – Data out of phase one — it is the single easiest scope reduction available.
Demo the Journeys segment builder over Dataverse before anyone sees the Data side. Clients frequently discover it does what they needed all along.
If Customer Insights – Data is in scope, sequence it first. Map, Match and Merge is the long pole, and journeys built against half-unified profiles have to be rebuilt.
Push back on enabling leads as an audience unless there is a lead-specific journey somebody has designed. It doubles the journey count for a benefit nobody has articulated.
Before go-live, check audience configuration field mappings for every entity you enabled, and send a live test through each one. Missing recipient fields fail quietly.

Worth another look if audience configuration gains defaults for customer profiles, or if mixed contact and lead audiences become supported.