What it does

The unified data view is the last configuration step. Having matched records across tables, you decide which columns appear on the unified profile, which get combined into one field, and — when two sources disagree — which value wins.

Key facts

• Three conflict resolution policies per merged field: Importance (default, takes the first non-null value following the table ranking order), Most Recent, and Least Recent. The recency options need a date or numeric field to sort on.
• Importance ranking is reorderable per merged field, so the table that wins for email doesn't have to be the table that wins for address.
• Field operations available: combine, separate (undo a combine), rename, exclude, and reorder.
• Combine group of fields treats related columns as one unit — the classic case is a postal address, so you don't end up with a street from one source and a postcode from another. Supports up to 10 fields across up to 15 data sources.
• CustomerId is a generated GUID. You can optionally nominate up to 5 stable fields to base it on — a government ID or similar. Volatile fields such as phone or email are a poor choice here.
• Clustering groups related profiles. Household clustering happens automatically when Person.LastName and Location.Address are present; Custom clusters use rules similar to match rules. Each cluster member gets a common cluster ID.
• Excluding a field removes it from the unified profile entirely — it isn't hidden, it isn't there.
• After this step you move on to review and create customer profiles.

When to use / skip

There's no skipping it, but there is a lot of scope for over-engineering. The default behaviour — Importance ranking following table order — is right more often than people expect, because you usually did think hard about table order in the match step.

Spend effort on the fields where sources genuinely conflict and where the conflict has consequences. Contact details are the obvious ones: which email do we actually send to, which mobile do we text, which postal address do we ship to. Consent and preference fields matter even more, though those usually want a deliberate policy rather than a merge rule.

Skip the fine-tuning for descriptive fields nobody acts on. Setting a bespoke recency policy on a "preferred colour" attribute is time you could spend validating addresses.

Household clustering is worth a conversation on consumer builds and pointless on most B2B ones. It arrives automatically if the semantic types line up, so know whether you want it before it shows up unannounced.

Configuration decisions

• Which fields get merged into a single unified column and which stay source-specific. Keeping both a merged email and the per-source emails is common and defensible.
• The conflict policy per merged field, and the importance ranking behind it. Write down the reasoning; someone will challenge it.
• Which date column drives Most Recent, and whether it's a real business timestamp or a technical modified date that ticks whenever anything in the row changes.
• Which field groups need combining as units — address is nearly always one, and name components often should be.
• Whether CustomerId is based on nominated stable fields or left as a system GUID, given that the choice affects how stable profile identity is across runs.
• Whether household or custom clustering is enabled, and what the client will actually do with the cluster ID.

Gotchas

• Importance takes the first non-null value, so a source with a populated-but-wrong value beats a source with a null and correct-by-omission. Completeness is not correctness.
• A technical last-modified date used for Most Recent will favour whichever system writes most often, not whichever system holds the best data. Check what the column actually means before you rely on it.
• Not grouping address components produces Frankenstein addresses that look plausible and fail delivery. It's the single most common merge defect on real projects.
• Excluding a field is not reversible in the sense people assume — you can add it back, but anything built on it in the meantime has to be rebuilt.
• Choosing volatile fields for the CustomerId key means profile identity churns whenever a customer changes their phone number, which ripples into anything storing the ID externally.
• Household clustering appearing automatically surprises clients who never asked for it. If they're not expecting profile grouping, explain it before they find it.
• The 10-field, 15-source ceiling on grouped fields is generous but real, and wide multi-source address models can bump it.

Consultant notes

• Run a workshop on contact details specifically. "Which system owns the customer's email address" is a governance question dressed as a configuration one, and the answer belongs to the client, not you.
• Demo two conflicting records and show which value lands on the profile. It makes the importance ranking concrete in a way a settings screen never will.
• Warn anyone integrating downstream that CustomerId is stable across runs but can change when profiles split, with the previous value tracked. Systems that store it need to handle that.
• Push back on merging fields "because they have similar names". Merged fields are a commitment; separate source fields cost almost nothing and preserve lineage.
• Before go-live, sample twenty merged profiles against their source records and check the address, email and phone each came from the source the business expects.

---

Worth another look if the client changes source system priority, or adds a source that should outrank the current primary for contact details.