How many data sources to bring into phase one

What it does

Phase one scoping is the decision about how many source systems go into the first unification run. Microsoft's own unification guidance points the same way: start from a basic set of rules against a single primary table, add progressively, and drop what doesn't improve the result. The scoping question is really that advice applied to sources rather than rules.

Key facts

The recommended pattern is to compare each table to the primary table rather than every table to every other table. Full cross-comparison costs a lot of runtime for very few extra matches.
Deduplicate each table first so each customer is one row before cross-table matching runs.
Deduplication rules combine as OR conditions to form match groups; match rule conditions combine as AND.
Run exact conditions before fuzzy ones so fuzzy comparison works on a reduced candidate set, and pair every fuzzy condition with at least one exact condition.
Add rules progressively and remove those that don't improve results, checking the Unique records statistics as you go.
Unification runtime is visible under Settings > System > Status > Match.
Active segments and active measures share a combined ceiling of 1,000, and a measure copied to Dataverse is capped at 10 million rows.
Relationship paths support up to 20 levels of depth, which is far more than any sane model needs but does cap exotic designs.
System refresh runs daily or weekly, up to four times a day. Every source added extends that window.
Sandbox environments don't support scheduled refreshes, so a large phase-one scope can't be soak-tested on a like-for-like schedule.
A Dataverse source depends on a 48-hour Delta log window; more sources means more things that break together when a refresh is missed.

When to use / skip

Three sources in phase one. That's my answer nine times out of ten: the system of record for customer identity, the system holding transactions, and one system the business is loudest about. Everything else waits for phase two, and phase two starts about six weeks after go-live when people trust the profiles.

The reason isn't technical capacity — the platform will take more. It's that each additional source multiplies the matching conversation, and matching is the part that needs business judgement rather than configuration. Four sources with clean rules and an owner beats nine sources nobody can explain. It also keeps the refresh window short enough that you can iterate daily during build, which matters more than any feature.

Go wider when the sources are genuinely homogeneous — a retail client with eleven country instances of the same commerce platform, identical schema, same identifier. That's one source eleven times, not eleven sources, and bringing them all in at once is fine.

Go narrower — two sources, sometimes one — when the client's data quality is poor enough that phase one is really a proof that unification is possible at all. If the first extract you're handed has 30% missing emails and no consistent customer number, scope to the two systems that matter and spend the saved time on data quality upstream. Nobody thanks you for a unified profile built on rubbish.

Watch for the client who wants a system in scope purely because a department is paying for the project. That's a political requirement, not a data one. Take the source in at phase two, ingest it early so they can see their data on screen, and keep it out of the matching rules until it's earned a place.

Configuration decisions

Which system is the primary table, which fixes the table order and therefore what can match against what.
Whether a source is ingested but excluded from unification — visible in Tables, not contributing to profiles — as a middle path for political scope.
Where deduplication happens per source: upstream in the system of record, or in the Deduplication stage.
Which activity data comes in for phase one, given activities aren't part of profile matching but do drive measures and segments.
The refresh cadence you commit to, and whether the phase-one scope still fits inside it when volumes triple.
Whether phase two sources will need the table order changed, which is worth designing for now rather than discovering later.

Gotchas

Adding a source later can change the table order, and changing the order changes matching, which can split profiles and reassign CustomerId values that downstream systems have stored.
Every source added lengthens the unification run. Teams discover at UAT that the nightly window no longer fits, usually the week before go-live.
A source with no match rule defined against the primary table contributes nothing but still costs ingestion and refresh time. The warning icon on the match pair is the only hint.
Ingesting a source "just to look at it" quietly commits you to refreshing it forever, because someone always builds a segment on it.
Phase-one segments built during UAT get auto-deactivated after 45 days without use, so a delayed go-live leaves the client with dead segments on day one.
Sources with a Dataverse dependency all share the same 48-hour Delta log exposure. One missed schedule takes out the lot rather than one feed.

Consultant notes

Put the phase-two source list in the phase-one document, with names against each. It converts "why isn't my system in" into a scheduling conversation.
Demo the Tables page with the client's own data early, even for sources outside unification. Seeing their records on screen defuses most scope arguments.
Push back on ingesting anything without an identified matching column. If nobody can say how it joins to a customer, it isn't ready.
Before go-live, run the full refresh at production volume and time it. Then agree what happens when it overruns — which is a business decision about staleness, not an operational one.

Worth another look if refresh scheduling gains more than four runs a day, or if sandbox environments start supporting scheduled refreshes.