You need Data Cloud, which Salesforce now calls Data 360, when the customer data behind an important decision lives in several systems and has to be unified into one profile that segments, automations or Agentforce agents can act on. You probably do not need it yet if the data you need is already in your Salesforce org, or if your core CRM data is not clean enough to trust. Because it is priced on consumption, the best starting point is a specific use case, not a platform project.
What Data Cloud actually does
Data Cloud is easiest to understand as a pipeline that takes data from many places and turns it into something the rest of Salesforce can use. Salesforce describes the stages roughly as follows:
| Stage | What happens | The question it answers |
|---|---|---|
| Connect | Data arrives through connectors, from Salesforce and external sources, or is accessed in place in a data warehouse or lake without copying it | Where does the data we need live? |
| Harmonize | Source fields are mapped to a standard data model, so an "email" from three systems means the same thing | Are we describing customers consistently? |
| Unify | Identity resolution uses matching and reconciliation rules to link records that belong to the same person or account into a unified profile | Which records are the same customer? |
| Analyze and segment | Calculated insights (such as lifetime value) and audience segments are built on the unified profiles | Who should we act on, and why? |
| Activate | Profiles and segments are pushed back to Salesforce apps, marketing channels and other platforms, or used to trigger automation | Where does this data need to show up? |
| Ground AI | Agentforce agents use the unified data, and unstructured content such as documents and call logs, as context | Does the agent know enough to answer correctly? |
The value is in the last three rows. Data that is connected and unified but never segmented, activated or used by an agent is an expensive copy.
One early design choice is whether to bring data in or leave it where it is. Salesforce offers zero-copy access to several major data warehouses and lakes, which suits companies whose data team already treats the warehouse as the source of truth. Ingesting data through connectors suits sources that have no other good home. Most real architectures use both, and the choice should follow who owns each dataset and how fresh it needs to be, not which option sounds more modern.
Signs you need it
- Decisions depend on data outside Salesforce, such as product usage, orders, billing, web behavior or a risk or servicing system, and people currently stitch it together by hand.
- The same customer exists in several systems under different identifiers, and nobody can produce one reliable view.
- Marketing wants to segment on behavior or transactions that the CRM does not hold.
- You are building Agentforce agents that need context from outside the CRM to answer correctly.
- Your data team already maintains a warehouse, and you want Salesforce to use that data without building another copy of it.
Signs you do not need it yet
- Almost everything your use case needs is already on Salesforce records; reports, Flow or a simple integration will do.
- Your CRM has a known duplicate problem, inconsistent fields or no agreed definitions for basic terms like "active customer".
- Nobody can name the first decision or action the unified data would change.
- There is no owner for data quality after launch.
- Source systems are about to be replaced, so any mappings built now would be rebuilt soon.
None of these rule Data Cloud out permanently. They mean the money is better spent first on CRM cleanup, integration or definitions, which Data Cloud would need anyway.
Prerequisites for a first use case
- One named use case with a measurable outcome, such as a segment marketing will send to or an agent that answers a defined set of questions.
- A list of the source systems involved, with an owner for each and a way to access the data.
- Agreed identifiers for matching: email, customer number, account ID or a combination.
- A decision about which system is authoritative for each important field.
- Consent and privacy requirements reviewed, especially for consumer data and regulated industries.
- An estimate of which Data Cloud actions the use case will consume, reviewed against your contract.
- A plan for who monitors data quality and usage after go-live.
That last consumption point matters. Salesforce describes Data 360 as a consumption-based product with credits drawn down as you use it, alongside profile-based options. Knowing which actions your first use case needs, and how often they run, keeps the bill predictable and the scope honest.
An example of starting with architecture
A business lender receiving 24,000 leads a month had customer data spread across a risk engine, a servicing platform and Salesforce, and a sales team that could not work every lead. Rather than switching everything on at once, the engagement produced a Data Cloud architecture and phased roadmap to unify 10 terabytes of data from those systems, alongside a lead-prioritization framework the team could use immediately. The result was a scalable foundation for grounding AI in full customer context across finance, underwriting, collections and sales, built in phases rather than all at once.
That sequence is a useful template. Start with the decision you want to improve, design the architecture that serves it, deliver value from existing data where you can, and add sources in phases.
