Build a single customer view without losing the source of truth

Start with the questions the view must answer

Choose a small set of operational questions: who owns the account, which cases are open, what orders are active and whether finance needs to be consulted. Identify the minimum data needed for those answers. A service agent may need a payment-status flag without seeing every financial document.

Define whether the view represents a person, organisation, household or branch. Keep one-to-many relationships such as orders and tickets separate from identity fields. Microsoft Customer Insights describes unification as a process involving source selection, deduplication, matching and a unified view; a similar separation helps make any implementation easier to reason about.

Build identity links that can be corrected

Store a stable cross-reference between the unified identity and each source record. Use reliable identifiers where available and carefully reviewed matching rules elsewhere. Shared contact details, company renaming and acquisitions can make apparently obvious matches wrong.

Microsoft's matching documentation shows that normalisation, rule order and exceptions influence results. Test your rules with known matches and known non-matches. Include an explicit process for splitting a false match or linking a missed match, and retain enough provenance to understand which source relationships were affected.

• Keep placeholders and shared values out of strong-match rules.
• Review ambiguous matches before exposing combined information.
• Test branches, subsidiaries and customers with multiple roles.

Resolve field ownership and freshness

Choose the authoritative source for each important field and explain how conflicts are handled. A recently entered value is not necessarily more trustworthy than an older verified one. For example, an order's delivery address may differ legitimately from the account's registered billing address.

Display timestamps and source links where freshness matters. Define acceptable delay separately for profile information, open cases and payment status. If a source is unavailable, retain a clear last-known state or show that the field cannot currently be confirmed rather than silently treating missing data as an empty value.

Apply permissions to the combined result

Combining data can reveal more than each system reveals on its own. Check the viewer's role and purpose before displaying sensitive fields or cross-system relationships. A central profile should not become a shortcut around the finance, HR or customer-service system's access controls.

Validate the view through real user tasks and monitor reconciliation differences. Keep correction responsibilities with named source owners so the dashboard does not become another competing master record. Expand the view only when each additional data source improves a defined task and can be maintained reliably.