Data 360 & Data Architecture

A unified profile is not a golden record

JSBC Labs17 September 20268 min read

Unification answers identity—not authority

A Data 360 implementation matches four source profiles and presents one unified customer. The team declares that the golden record is finished, then discovers that service trusts the CRM address, fulfilment trusts commerce, finance requires a verified legal name and marketing must honour channel-specific consent. One person does not make every displayed value authoritative.

Identity resolution answers a narrower question: which source records probably describe the same entity, and which values should the unified view present? Master-data authority answers who may create, correct and certify a fact. Treating those questions as interchangeable turns a useful analytical profile into an unsafe operational master.

Separate four decisions that projects often collapse

A sound design distinguishes identity, value selection, authority and use. Match rules decide which records link; reconciliation decides which value appears; source governance decides where a fact is mastered and corrected; activation policy decides whether it may be used for an audience, workflow or agent.

Salesforce documents match and reconciliation as separate parts of an identity resolution ruleset. That separation is technically important, but the enterprise must add the other two decisions. A source sequence can prefer CRM for a phone number; it cannot prove the number was verified, current, permitted for SMS or appropriate for a collections process.

Start with a decision, not a 360-degree aspiration

Before building a ruleset, name the decision the profile must improve: suppressing duplicate marketing, consolidating service history or grounding an agent with recent product ownership. Each use case tolerates missed links, incorrect links, latency and sensitive-data exposure differently.

Profile the contributing sources against that decision: identifiers, update cadence, completeness, verification state, duplicates, household sharing and known data-entry patterns. Salesforce's Trailhead guidance explicitly asks teams to inventory data locations, identifiers, shared fields, journeys and quality before unification. The practical architecture begins there—not with the default ruleset wizard.

A match rule encodes business risk

Data 360 supports exact, fuzzy and normalized match methods for supported fields. Exact matching requires the same value, fuzzy matching tolerates similarity for first names, and normalization can compare formatted email, phone and address values consistently. Combining criteria can recover fragmented identities, but every broader path also creates another way to merge different people.

False positives and false negatives are not symmetrical. A missed link may weaken personalisation; combining two patients, beneficiaries or account holders can expose data or trigger a wrong action. Assign every match path a harm assessment and evidence threshold. Use stronger identifiers for high-consequence cases; a shared address or recycled phone number is not proof of personhood.

Test clusters, not only match percentages

A consolidation rate tells you how much source data was grouped; it does not tell you whether the groups are correct. A looser rule can make the dashboard look impressively unified while creating a few very large, implausible clusters. An overly strict rule can leave obvious duplicates apart while still producing a stable overall percentage.

Build a labelled sample with known matches, non-matches and difficult boundary cases. Review cluster-size distribution, source combinations and changes after each revision. Trace representative profiles from source to unified result, including sparse records and shared contact points. Release when errors are acceptable for the named use—not when one global metric turns green.

Reconciliation is presentation logic, not truth

Salesforce exposes Last Updated, Most Frequent and Source Sequence reconciliation strategies, with rules available at object and field level. Each is useful and each can be wrong. The newest value may come from an unreliable batch; the most frequent value may merely repeat a historic error; the preferred source may be authoritative for loyalty tier but not for legal name.

Define precedence per attribute and purpose. Record why a source wins, what quality controls it performs and how quickly corrections arrive. Where no rule is defensible, preserve several source values instead of manufacturing certainty. A unified view may correctly show multiple emails or addresses with provenance while a downstream process selects only the verified, permitted contact point.

Preserve lineage and the correction path

Source records remain essential evidence. A unified profile should relate records without erasing which system supplied a value. Data owners still need to know where an error originated, who can correct it and when the change returns through ingestion and identity resolution.

Do not write reconciled values back to every source by default. That can overwrite system-specific meaning and create a feedback loop in which a selected value becomes frequent merely because it was replicated. Write-back needs an explicit contract: target owner, validation, conflict policy, audit trail and retry behaviour. Otherwise keep unification read-oriented and send corrections to the true system of record.

Do not build permanent dependencies on a unified ID

Salesforce documents that a Unified Individual ID can change when profiles merge or split. When two clusters become one, an existing ID may be retained while another changes; when a cluster separates, one resulting profile can retain the old ID while others receive new IDs. Rules and source data evolve, so cluster identity evolves with them.

Treat the unified ID as a platform-managed resolution key, not an eternal enterprise customer number. Downstream stores should retain relevant source identifiers, activation identifiers and effective dates, and they should tolerate refreshed membership. If a legally or operationally persistent customer key is required, master it in a governed domain designed for that stability rather than borrowing an identity-resolution output.

Create a controlled path for known exceptions

Some relationships are known with more certainty than generic matching can provide. Salesforce's Identity Match capability lets organisations load explicit positive or negative links into an IdentityMatch data model object so selected records can be forced together or kept apart during identity resolution. Examples include a confirmed lead conversion or a steward-reviewed false merge.

An override is powerful governance data, not a convenient patch. Capture the evidence, requester, approver, reason and review date. Restrict who can create links, test their effect on surrounding clusters and provide a reversal process. If teams need hundreds of manual exceptions, investigate source identifiers and match design instead of building a shadow identity team around the ruleset.

Identity, consent and activation remain separate controls

Matching records does not grant permission to use all their attributes. One person can have different communication choices by brand, channel, purpose, region or account relationship. Data 360's security architecture describes consent awareness and policy enforcement across the lifecycle through activation; those controls must survive unification rather than being flattened into one marketable flag.

Before activation, evaluate identity confidence, current consent, suppression, data classification and destination purpose. Pass only the attributes the target requires and preserve auditability from source to segment or action. The same unified profile can appropriately support a service interaction while being excluded from a campaign. A 360-degree view is not a 360-degree licence to act.

The JSBC Labs view

A unified profile is valuable precisely because it does not need to replace every operational record. It provides a governed identity graph and a purpose-built view across sources. Match rules link; reconciliation rules select; source domains remain accountable for truth; activation controls decide permitted use. Keeping those boundaries clear reduces both duplicate experience and centralised data risk.

Start with one decision, conservative identifiers and a labelled validation set. Document attribute-level authority, monitor cluster behaviour, preserve lineage, plan for ID change and govern overrides and consent. Call the result a golden record only if the organisation has actually defined stewardship, correction, survivorship and operational authority. Until then, call it what Salesforce does: a unified profile—and design the downstream systems accordingly.