Getting Data 360 right the first time: the decisions made before ingestion

A connector takes an afternoon. Ingesting the first object takes another. Then somebody asks which of the four email addresses now sitting against the same person is the one a service agent should use, and the project stops for six weeks.

Salesforce Data 360, which plenty of teams still call Data Cloud, is forgiving at the point of ingestion and unforgiving afterwards. Connecting a source is deliberately easy, and the published connector list is long enough that most organisations can get data flowing in the first week. Deciding what that data means, whose version of an attribute wins, and which records are genuinely the same customer is the part that carries cost.

Every one of those decisions is cheaper before the first connector runs than after, because afterwards something downstream has already acted on the answer.

#Unified is not one decision, it is one per use case

The word does most of the damage. A programme is chartered to build a unified customer view, everybody nods, and four teams walk out of the room with four different pictures in their heads.

A service agent needs the entitlement, the open orders and the last three interactions, and it needs them to be about the person on the phone right now. A marketing journey needs consent, channel preference and engagement history, and it needs them to be about a person who may share a household and a surname with somebody else on the list. A billing statement needs the legal entity, which is frequently not a person at all. Finance and service can look at the same two records and disagree, correctly, about whether they describe the same customer.

So the decision is not global. Write one sentence per use case, in this shape: for this use case, two records describe the same entity when this test passes, and the attributes it needs are these. If nobody can write that sentence for a use case, that use case is not ready to be built, and building it anyway produces a unification that satisfies none of the four teams.

#Identity resolution: loose matching is worse than no matching

Identity Resolution is the capability that decides which source records collapse into one profile. It has two failure modes and they are not symmetrical, which is the single most important thing to understand before configuring it.

Under-matching leaves the same customer sitting as three profiles. It is visible, irritating and reversible. Somebody complains that the agent cannot see an order, the rule gets loosened, life continues.

Over-matching merges two different customers into one profile. It is silent. The merged profile looks better than the correct ones, because it has more attributes populated and a richer history. Nothing on a dashboard distinguishes it from a successful match. It surfaces months later, when one customer sees the order history of another, or when a suppression flag applied to one person quietly silences somebody else, or when consent recorded by one individual is inherited by a stranger.

The inputs that cause trouble are predictable, so name them before you meet them. Shared household email addresses. Generic mailboxes, such as an accounts address used by every contact at a business account. Family members at one postal address with the same surname. Common names in markets where a small set of names covers a large share of the population. Test records never removed from the source. Migrated records where a legacy system reissued identifiers.

The approach is to start strict, then loosen with evidence. Before configuring anything, build a labelled set of record pairs: perhaps two hundred a person has judged, half that must match and half that must not, drawn from real data and including the awkward cases above. That set is a regression test, and it is what lets you loosen a rule later without guessing.

Then sample the output. Read fifty merged profiles by hand after the first run. It is unglamorous, it takes an afternoon, and it is the only technique we know of that reliably catches an over-match before a customer does.

#Source of truth is an attribute-level decision

This is the distinction most teams miss, and it usually survives all the way to the first data quality argument.

Naming the CRM as the source of truth is a slogan, not a design, because no single system is right about everything it holds. The billing platform has the address that invoices actually reach. The service system has the address an engineer was dispatched to. The ecommerce platform has the email that received a delivery confirmation last week. The consent platform has consent, always, with no exceptions and no inheritance. The CRM may hold the best company name and the worst phone number in the estate.

So the artefact you need is a table of attributes, not a table of systems. For each attribute that matters to a named use case: which source wins, what the tie-break is when the winning source is empty, and whether recency is actually the right rule.

That last question is worth pausing on. Last-write-wins is a default rather than a policy, and it is wrong more often than it looks. A customer who updates a delivery address in a portal has probably given you the better address. A batch import that rewrites every record with a normalised country code has changed nothing meaningful and will still win on recency. Decide per attribute whether newest wins, whether a nominated system always wins, or whether a system wins only when it is populated.

#Harmonisation: the model is a commitment

Harmonize is where source fields are mapped into shared objects, and the mapping itself is mechanical. The modelling underneath it is not, and it is not a named product feature: it is ordinary data architecture, applied inside the platform.

The decisions that hurt are about granularity. Does an order mean the header, the line, or both, and which one do downstream consumers count? Is a contact a person, or a person in a role, so that the same human at two accounts is one profile or two? Is an interaction a message, a conversation, or a case? None of these have universally correct answers, and every one of them reads as obvious to whoever proposes it.

Changing the answer later means reprocessing history and revisiting every consumer built against the old shape. That is the definition of an expensive reversal, and the pattern generalises well beyond this platform: the wider version is set out in the data model decisions you cannot undo.

Write the definitions down in business language, have them read aloud to a process owner, and only then map anything. A definition that survives being read aloud to the person who runs the process is usually right.

#Copy or reference: the Zero Copy trade-off

Zero Copy lets Data 360 work with data where it already lives rather than ingesting a duplicate. Salesforce sets out the mechanics in its overview of how the platform works, and the architectural trade is straightforward once stated plainly.

Referencing avoids duplication, avoids a sync to operate, and leaves governance with the system that already holds the data. In exchange, the responsiveness and the availability of that source become part of your customer experience. A warehouse that is fine for analytics at nine in the morning may not be fine as a live dependency during a conversation.

Copying gives predictable latency and isolation from source outages, at the cost of storage, a refresh cadence to manage, and a window in which the copy is wrong.

Decide per object, against three questions. How often does it change? What staleness does the consuming use case genuinely tolerate, as opposed to what the business would prefer? Can the source carry the query pattern you are about to point at it? Slow-changing reference data is usually worth copying, because it is cheap and never wrong for long. Wide, rarely-read historical tables are natural candidates for referencing. Anything an Agentforce agent reads mid-conversation should be assessed on availability first, because a live read that fails during a customer conversation is a worse failure than an answer that is an hour old.

Most service use cases tolerate slightly stale data far better than an outage, which usually settles it, and it should still be settled per object rather than once by policy. Where an integration belongs more generally is covered in pick the integration pattern first.

#The pre-ingestion decision checklist

This is the list we work through before a connector is configured. It takes two or three sessions with the right people, and it is the artefact that makes the rest of the build boring.

Read down the third column and the shape of the work becomes obvious. Almost none of it is configuration, which is why a plan costed on build effort alone is wrong by the width of this table.

#Ownership: unification decays quietly

An unowned unification degrades, and the degradation is invisible because nothing fails.

Source systems change shape without telling you. A field is repurposed. A vendor normalises casing on export. A migration reissues identifiers, so that yesterday customers arrive as new ones. A list import lands without country codes and the phone-based match rule stops firing for an entire market. None of these produce an error. They produce a match rate four points lower than last quarter, which nobody is looking at.

So name an owner per source and per ruleset, and give them two specific things to watch. The first is match rate over time, at a grain fine enough to see one market or one source move on its own. The second is the merge and split rate month over month, because a spike in either direction is the earliest signal that a source changed underneath you.

The change gate matters as much as the review. Connecting a new source is the moment match rules are most likely to break, because a new source brings new identifier formats and a new population. Treat a new connector as a change to identity resolution rather than as a simple addition, and re-run the labelled pair set before it goes live.

#What is expensive to reverse, and what is not

The caution above is not evenly distributed, and treating every change as dangerous is its own failure mode.

Cheap: adding a source, adding an attribute to an existing model, adding a use case that reads unification you already trust, tightening a match rule before anything has consumed it. These should not be governed as though they were expensive.

Expensive: changing entity granularity, changing match rules after unified identifiers have been used by segments, agents or reports, changing the source of truth for an attribute written back into an operating system, and moving an object between copy and reference once a consumer depends on its response times.

The pattern is consistent. A decision costs what it costs to reverse in proportion to how far its output has already travelled, which is why the checklist sits before ingestion rather than before go-live.

#Where teams get stuck

Three failure shapes, and each is recognisable early enough to avoid.

Ingest first, model later. The programme reports good progress for a month, because connectors are visible and definitions are not. The modelling debt is paid later, at reprocessing prices, during the first use case with a date attached.

Treating it as an IT project. Identity resolution is a business decision wearing technical clothing, because only the process owner can say whether two records are the same customer for their purpose. A data team left to decide alone will pick something defensible and generic, and generic is exactly what fails on the household email address.

Starting with the largest source. Volume is not what resolves uncertainty. Start with whichever two sources most disagree about identity, because that pair contains the decisions you actually need to make, and it will surface them in a fortnight rather than a quarter.

#The first three weeks

If the programme is funded and nothing has been connected yet, this is the sequence to run.

The first week is use case statements and the attribute ownership table, with process owners in the room rather than consulted afterwards. The second week is match rule design and the labelled pair set, using real data with the awkward cases included deliberately. The third week is the copy or reference decision per object, the freshness each consumer needs, and the names written against each source and each ruleset.

Then connect something. The connector still takes an afternoon, and by that point it is worth what it costs to run. Everything downstream, including whatever Agentforce work follows, inherits the quality of those three weeks rather than the quality of the ingestion. The readiness dimensions at the agent layer are set out in what separates an Agentforce rollout that is still running in six months, and grounding, the one that fails most often, usually turns out to be a Data 360 question wearing an AI label.