Data 360 use cases, and the data each one actually demands

A Data 360 workshop usually ends with twenty things written on a wall, and every one of them is genuinely achievable. What the wall does not record is that four of them are a fortnight of mapping, three are a quarter, and two are a data programme that will outlast the sponsor who asked for them. The platform is not what separates those groups. The state of the source data is.

Data 360, which plenty of teams still know as Data Cloud, is very good at unifying, modelling and activating data that can be joined. It has no opinion about data that cannot. So the useful artefact coming out of a discovery is not a prioritised wish list. It is a prerequisite list: for each candidate, the systems it draws on and the one specific data quality it will not work without.

#Why readiness sets the price, not the platform

The work inside a Data 360 implementation splits roughly into three parts. Bringing source data in, mapping it into a common shape, and resolving records that describe the same person or account. Salesforce names the first two on its Data 360 page: Harmonize covers mapping disparate sources into a consistent model, and Identity Resolution applies match and reconciliation rules to produce unified profiles.

Neither of those is where projects overrun. Mapping is tedious and predictable. Ingestion is mostly a connector question. The overrun sits in the sentence nobody wants to say out loud in a workshop: there is no field in any of these systems that reliably links this record to that one. Identity Resolution matches on rules you give it. It cannot manufacture a link that no source system ever recorded, and a use case whose value depends on that link is not a configuration task, it is an identifier programme with a use case attached.

That is the whole argument. Score a candidate on what it demands rather than on what it delivers, and the backlog reorders itself.

#The use cases and what each one demands

This is the table we build early in a discovery and keep visible for the rest of the programme.

Read the third column first. That is the prerequisite, and the prerequisite decides the fourth column.

#Unified profile for service context

The cheapest version of this is also the most valuable, and it is smaller than people expect. A service consultant taking a call wants to know who this is, what they own, what they have contacted us about recently, and whether anything is currently broken. That is four questions, not a 360 degree view of anything.

Scoped that way the prerequisite is narrow: CRM, the system that holds what the customer bought, and the service record. In most organisations those three already share an account number or a customer reference, because billing has needed one for years. Where that is true, this is honestly a few weeks of harmonisation plus a rule about precedence.

Where it breaks is the precedence rule rather than the join. Two systems hold an address, they disagree, and nobody has ever had to decide which is authoritative because no screen previously showed both. Somebody now has to decide, and that somebody is a business owner rather than an architect. Budget calendar time for it, not effort.

The temptation is to widen the scope while you are in there, since the pipes are open and adding a fourth source looks free. It is not free: every extra source adds a mapping to maintain, a refresh to monitor and another candidate for the precedence argument. Ship the four questions, then widen.

#Segmentation for marketing

Segmentation is the use case most often given as the reason to buy a customer data platform at all, and Salesforce's own framing of what a CDP does leans on exactly this. The technical prerequisites are moderate: behavioural data with timestamps, engagement data and purchase history, all attached to a contact that Data 360 can resolve.

The prerequisite that actually bites is definitional. Ask three people what an active customer is and you get three answers, all defensible, all producing different segment sizes. Ask what counts as a purchase when a subscription renews automatically. Ask whether a household is one customer or four.

None of that is a data engineering problem, and all of it changes the numbers. A segmentation build that starts before those definitions are written produces segments marketing does not trust, and untrusted segments do not get used, which is a more expensive failure than a late delivery.

#Grounding for agents

Agents built on Agentforce need a small number of facts and need them to be right. That inverts the usual readiness question. Breadth barely matters. Field-level accuracy, freshness and permission matter enormously, because the agent will state these values to a customer in a sentence that reads as authoritative.

So the prerequisite is not a broad unification, it is a bounded one with a quality bar. Pick the fifteen or twenty attributes the agent is permitted to read. Establish how stale each one may be, in hours rather than in adjectives. Confirm that the permission model still holds when an agent, rather than a logged in person, is doing the reading.

That last point is where most grounding work goes wrong. A field correctly restricted on a CRM page layout is not automatically restricted in a unified profile, and the moment an agent can retrieve it, the restriction has to be real in the data layer rather than in the interface. Which agent candidates are worth attempting at all is a separate question, covered in Agentforce use cases that survive a business case, and the build discipline in Agentforce implementation best practices.

#Churn and risk signals

This looks like a modelling problem and is almost always a measurement problem. To score churn risk you need something that moves before the customer leaves: usage, engagement, service contacts, payment behaviour. The prerequisite is that the moving thing is captured per account, on a consistent cadence, over a period long enough to contain examples of the outcome you care about.

Two failures recur. The first is telemetry that exists at device or session level and cannot be rolled up to the account that pays, which is the identity problem again in different clothes. The second is that nobody has written down what churn means here. Non-renewal, downgrade, dormancy and a formal cancellation are four different events, and a signal built on a blend of them predicts a blend of them.

Where history is short or the definition is absent, the honest advice is to start capturing and defining now and to build the signal in two quarters. That is an unpopular thing to say in a workshop, and it is cheaper than a risk score nobody can act on.

#Cross-channel measurement

This is consistently the most expensive item on any Data 360 wall, and it is consistently presented as though it were the same size as segmentation. It is not, because it requires an identifier to survive a journey that starts anonymous and ends known.

Somebody browses without signing in. They come back on a phone. Weeks later they buy through a call centre. Attributing that purchase to the original session demands a link most estates simply do not record, and no amount of harmonisation creates it. The realistic path is a deliberate identifier programme: a first party identifier issued on the web, persisted, and captured at the moment of a known interaction such as a sign-in, a form or a purchase.

That programme is worth doing. It is not a use case, it is infrastructure, and calling it a use case is how it ends up scoped as a sprint. Salesforce publishes a broad use case library that is useful for shaping ambition, and it repays reading alongside a frank note about which of those entries depend on identifiers you do not currently issue.

#Cheap, expensive, and the ones wearing a disguise

Sorting the list by demand rather than by value produces three groups.

Genuinely cheap. Bringing two or three systems that already share a customer reference into one profile and putting it in front of service staff. Real value, modest effort, and it produces the reference data the next use case will need anyway.

Fairly priced. Segmentation, once the definitions exist. Agent grounding, once the attribute list is bounded. Both are real projects with real timelines and neither of them is hiding anything.

Multi-quarter programmes wearing a use-case label. Cross-channel measurement without a persistent identifier. Churn scoring without account level usage history. Household level anything, in an estate that has only ever modelled individuals. These are legitimate ambitions and they should be funded as what they are, because a programme presented as a use case gets a use case budget and then quietly consumes a programme's worth of time.

#Sequence by shared prerequisite

Here is the part that changes delivery order more than anything else on this page. Look down the third column of the table and count how often the same prerequisite appears.

A resolvable person identity across CRM and the transactional systems is needed by the unified profile, by segmentation, by agent grounding and by churn scoring. One piece of work unlocks four candidates. The persistent web identifier, meanwhile, is needed by exactly one candidate, cross-channel measurement, and by nothing else on the list.

Sequencing by business enthusiasm ignores that structure entirely, and enthusiasm usually points at measurement, because that is the number the executive team argues about. Sequencing by shared prerequisite does the identity work first, delivers the service profile as its visible output, and then finds that segmentation and grounding are largely configuration on top of a foundation that already exists.

Cluster the candidates by what they demand, count the dependants of each cluster, and start with the cluster carrying the most. That single reordering is usually worth more than any technical decision taken later in the programme.

It also gives you a defensible answer to the question that follows every prioritisation meeting, which is why the sponsor's favourite is third. Third because it needs two things that do not exist yet, both of which are being built by items one and two, is an argument that survives contact with a steering committee. Because it scored lower is not.

#Where Zero Copy changes the picture

Zero Copy allows Data 360 to work with data held in an external platform without physically ingesting a copy of it. That genuinely changes the cost and the latency of reaching warehouse data, and it removes an argument about duplication that used to consume weeks of design time.

It does not change readiness. Data that could not be joined when it was copied still cannot be joined when it is queried in place, and a field that was inconsistently populated remains inconsistently populated. Zero Copy answers how do we reach it, not can we trust it. Teams reading it as a shortcut past the prerequisite list tend to rediscover the identity problem a month later with less budget left.

#What to produce before writing a single use case

Two artefacts, both short, both produced before any prioritisation meeting.

An inventory of customer bearing systems with, for each one, the identifiers it actually holds. Not the identifiers it is supposed to hold: run the query and record the fill rate. This is usually the first time anyone in the organisation has seen the truth in one place, and it settles arguments quickly, because a field populated on a third of records is not an identifier no matter what the data dictionary calls it.

A written definition of the three or four entities the use cases keep referring to. Customer, account, household, active. One paragraph each, signed off by someone with the authority to sign it off.

Both take about a fortnight between them and both remove a category of overrun that otherwise surfaces in month four, when the mapping is done and the profiles are wrong. The delivery practices that follow from them are set out in Data 360 implementation best practices.