Re-running unification and its dependencies

What it does

Once profiles exist, unification settings stay editable and re-runnable. Three run options give you increasing blast radius: test the rules only, rebuild the profiles, or rebuild the profiles and everything hanging off them.

Key facts

Run matching conditions only executes deduplication and match rules, updates the Deduplication_* and ConflationMatchPair tables, and touches nothing else. It's the rule-testing loop.
Unify customer profiles runs dedupe and match and updates the unified profile table, but does not rerun enrichments, segments or measures. Those refresh on their own schedule.
Unify customer profiles and dependencies does all of the above and reruns every dependency — enrichments, segments, measures, customer cards — automatically.
The Data > Unify page shows a tile per step with the profile count, mapped column count, and duplicates found. Tiles show Queued or Refreshing, and clicking the status opens Progress details with runtime, last run date, errors and warnings. You can cancel a job from there.
Available statistics include unique source records processed, matched and non-matched records after processing, and matched records only across all match pairs.
What you can change after go-live: add columns and tables, change column types, change primary keys, edit or add dedupe rules and merge preferences, edit match rules and their order, and rework the unified data view including the CustomerId key and clustering.
On the Matching rules tile specifically, you cannot add or delete tables — that's done back on the Customer data step.
Rules can be deactivated rather than deleted, which keeps the configuration without applying it. Rules can also be duplicated as a starting point.
Removing columns or tables goes through a dependency removal process, because segments and measures may be built on them.
Runtime is driven by data volume, data skew and the number of duplicate records. Heavily duplicated data is disproportionately slow.
System refresh is set at Settings > System > Schedule, off by default, daily or weekly, with up to four refresh times per day and a configurable time zone.

When to use / skip

You'll use the rule-testing run constantly during build and then rarely afterwards. Run matching conditions only is the one to reach for whenever you're tuning — it gives you match statistics without disturbing anything the business is using, which means you can iterate during working hours.

Unify customer profiles and dependencies is the heavy option, and most projects use it more than they should. If the schedule is going to refresh segments and measures in a few hours anyway, let it. Reserve the full cascade for the moments where the profile change is significant enough that stale segments would actively mislead someone — a new source going live, a match rule correction that moves thousands of profiles.

Don't rebuild unification to fix a data problem. If a source landed badly, fix the source and refresh it; re-running unification over bad input just produces the same bad profiles more slowly.

Configuration decisions

Whether the system refresh schedule is on at all, how often, and at what times relative to the client's upstream data loads. Refreshing before the source system has finished its nightly batch is a self-inflicted wound.
How many of the four available daily refreshes you use, and whether the business genuinely needs intra-day currency or just says it does.
Whether segments and measures keep their own custom schedules or ride the system refresh. Mixed schedules get out of sync quietly.
Which run option becomes the standard operating procedure for the client's admin team after handover, and who is allowed to trigger it.
How rule changes get tested before they hit production — deactivating rules and running matching conditions only, versus editing live.
What the acceptable unification window is, given data volume and duplicate density, and whether that fits inside the client's overnight batch slot.

Gotchas

Changing the system refresh time can knock custom segment and measure schedules out of alignment. Check them afterwards rather than assuming.
Unify customer profiles on its own leaves segments and measures reflecting the previous profile set until their next scheduled run. Someone will screenshot a segment count mid-window and ask why it's wrong.
Configuration is locked while unification is running. Plan rule changes around the schedule or you'll be waiting.
Heavily duplicated or skewed source data can stretch runtime well beyond what the client budgeted for the overnight window, and the effect isn't linear with row count.
Removing a table or column pulls you into dependency removal, which means dismantling segments and measures someone in marketing built and depends on.
Deactivating a rule is not the same as deleting it. Environments accumulate deactivated rules that later confuse whoever inherits the build.
CustomerId is stable between runs except when profiles merge or split — a merge keeps one of the previous IDs, a split issues a new ID and records the previous one. Downstream systems that key on CustomerId need to handle both cases.

Consultant notes

Make Run matching conditions only the default habit during tuning and say so in the handover pack. It's the single biggest time-saver in the build phase and almost nobody discovers it unprompted.
Time a full unification run on production-volume data before you commit to a refresh schedule. Estimates from a scaled-down dev environment are consistently optimistic.
Agree with the client who owns triggering the dependency cascade after handover, and under what circumstances. Left unowned, it becomes a support ticket every time a number looks odd.
Demo the Progress details pane, including cancelling a job. Admins who know they can cancel are far less nervous about running anything.
Before go-live, check the refresh schedule against the upstream load windows and confirm segment and measure schedules sit after unification, not across it.

Worth revisiting if the client's data volumes grow enough to threaten the overnight window, or if Microsoft adds finer-grained refresh control.