What it does

The first unification step. You pick which ingested tables hold customer profile data, choose the columns that come forward, nominate a primary key per table, and map columns to descriptive types like Person.FullName or Location.City. Everything downstream — dedupe, match, merge — only sees what you let through here.

Key facts

• Reached from Data > Unify > Get started, then Select tables and columns on the Customer data page.
• At least one table is required. One table is a valid unification: you get dedupe and a unified view without the match step.
• The primary key must uniquely identify every row — no duplicates, no nulls, no missing values. Supported types are String, Integer and GUID.
• At least one column must be mapped to Person.FullName or the customer name stays blank on the customer card.
• Semantic types are suggested automatically for recognised columns. The suggestions are decent but not right, and they are yours to review.
• You can create custom types by typing a name that isn't in the list. Unmapped columns are allowed — they still flow through, they just carry no semantic meaning.
• Columns that hold a public image URL should map to Person.ProfileImage to render on the card.
• Microsoft's own guidance flags more than 1,000 columns as the point where you should be weighing column value against processing time.
• Only tables with customer profile detail belong here. Transactional and activity data with a one-to-many relationship to the customer does not — that's activities, configured separately after unification.
• Finish with Save source columns, then Next to move to deduplication rules.

When to use / skip

This isn't optional — it's step one of unification, and it's the step that determines whether the rest of the configuration is pleasant or miserable. The real judgment call is scope: how many tables and how many columns.

The instinct on most projects is to bring everything in "so it's there if we need it". Resist it. Every extra column widens the unified profile, lengthens every run, and clutters the picker that segment builders will use for the next three years. Bring in the columns you need for matching, plus the columns a business user will genuinely put in a segment or on a card. Anything else can be added later — this step is editable after go-live.

On table count, be equally sparing at first. Two or three well-understood sources unified cleanly beats eight sources unified badly, and you can add sources incrementally without rebuilding.

Configuration decisions

• Which tables count as customer profile sources versus activity sources. Get this wrong and you'll unify transaction rows as if they were people.
• The primary key for each table — and whether it's genuinely stable across refreshes, or a surrogate the upstream pipeline regenerates.
• Which columns come forward, and the honest reason for each. Matching, segmentation, or display; if it's none of those, leave it out.
• Which columns get semantic types, and where you need custom types for client-specific concepts the standard list doesn't cover.
• Whether a person-level or account-level shape is being unified, and therefore which name and identity types you map. B2B builds get this muddled early.
• Whether to map identity columns such as Identity.Service.Email consistently across sources, since the match step reads far better when both sides are typed the same way.

Gotchas

• Nominating a primary key that isn't actually unique produces a failure well downstream from the table you got wrong. Profile the column before you nominate it.
• Semantic type auto-suggestions look confident and are sometimes wrong — a CustomerName column on an account table happily suggested as a person name is the classic.
• Forgetting Person.FullName gives you a working unification with nameless profiles on every card. It's easy to miss because nothing errors.
• Adding columns later is fine, but removing tables or columns once dependencies exist goes through a dependency removal process — segments, measures and enrichments built on them have to be dealt with first.
• Primary key changes after go-live are possible, but they reshuffle identity and you'll see CustomerId churn as a result.
• Bringing across every column from a wide CRM contact table is the single most common cause of a unification run that takes hours longer than the client expected.

Consultant notes

• Run a profiling pass on candidate primary keys and match columns before this workshop. Turning up with actual null and duplicate counts changes the conversation from opinion to fact.
• Tell the client explicitly that column selection is reversible but not free — adding is easy, removing after dependencies exist is a chore.
• Demo the customer card early, with names populated. It's the quickest way to make the semantic type mapping feel meaningful to a business audience rather than like data admin.
• Push back on "include everything". Ask which report or segment each column serves; the list halves in ten minutes.
• Before go-live, walk the mapped type list with someone who knows the source systems. Auto-suggestions that nobody checked are a recurring source of odd match behaviour.

---

Worth another look if Microsoft extends the semantic type list, or if the client adds a materially different source system.