Every Agentforce conversation we have ends up in the same place: the data. Not the model, not the prompt, not the agent builder. The data. That is why Salesforce sells Data Cloud, now rebranded Data 360, in the same breath as agents. It is the least exciting slide in the deck and the one that decides whether anything after it works.
We run a real Salesforce implementation and build our own CRM (Audexity), so we have lived both sides: the vendor platform and the hand-rolled version. Here is what Data 360 actually is, stripped of the keynote.
What Data 360 actually does
In one sentence: it takes customer data from everywhere, makes it one thing, and hands that one thing to the rest of Salesforce.
Concretely, that breaks into four jobs:
- Ingest. Connectors pull from your Salesforce orgs, marketing tools, web and app events, and external databases. Zero-copy connectors let it query a warehouse in place instead of duplicating it.
- Harmonize. Raw sources get mapped onto a common data model, so "customer" means the same thing whether it came from billing or support.
- Resolve identity. Matching rules collapse the three versions of the same person (two emails, one phone number, a typo in the surname) into a unified profile.
- Activate. The unified profile, plus calculated insights, becomes available to Flow, segments, dashboards, and agents, close to real time.
That last part is the point. A warehouse is where you analyse. Data 360 is where the CRM and its agents act on unified data.
Why AI needs it more than dashboards ever did
A bad dashboard is a wrong number someone squints at. A bad agent is a wrong action taken confidently, at scale. Dashboards tolerated messy data because a human sat between the number and the decision. Agents remove that human.
Dashboards forgave dirty data because a person was reading them. Agents do not have that person.
So the questions that used to be hygiene become safety questions. Which of these two contacts is real? Is this field current or two years stale? Is this agent allowed to see salary data, health notes, or ID numbers at all? If the answer lives in a spreadsheet someone keeps on their laptop, the agent will not find it.
Governance before agents, not after
The unglamorous half of Data 360 is the governance tooling, and it is the half we would use first.
Sensitive-data discovery. Before any agent reads a field, you want to know which fields hold personal or regulated data. Running classification across ingested sources turns "we think there is PII in the notes field" into a list you can act on.
Access policy on the unified layer. Field and record access needs to follow the data into the unified profile. An agent should inherit the permissions of the job it is doing, not the permissions of the integration user that happens to own the connector.
Lineage you can explain. When an agent does something odd, the first question is "what did it see?" If you cannot trace a unified profile back to its sources, you cannot answer that, and you cannot fix it.
None of this is new as an idea. What is new is that skipping it now has a visible failure mode.
See how we build and govern CRM data→
What is real, and what is hype
Real: identity resolution across sources is genuinely hard to build yourself and genuinely valuable. Zero-copy access to an existing warehouse removes a lot of brittle sync jobs. Having one governed profile that Flow, reports, and agents all read from is a structural improvement, not a feature.
Hype: "real time" means near real time for most sources, with ingestion schedules and processing lag you need to design around. "Unified" means unified according to your matching rules, which are only as good as the thought you put into them. And no platform decides for you which system owns which field. That is a business decision, and it is the one teams most often skip.
Cost is real too. Consumption-based pricing rewards scoping and punishes "ingest everything just in case." Start with the sources one use case needs.
How we would scope a first Data 360 project
Boring on purpose, same as our Agentforce playbook:
- Pick one outcome. For example: an agent that answers order-status cases, which needs orders, shipments, and contacts unified.
- Map the sources for that outcome only. Name the system of record for each field. Write it down.
- Classify before you connect. Run sensitive-data discovery and set access policy before the unified profile exists, not after an agent has read it.
- Tune identity rules on real data. Review a sample of merged profiles by hand. The false merges teach you more than the matches.
- Activate to a human first. Put the unified profile on the record page for agents to read before an autonomous agent touches it. If people trust it, the agent can.
Then widen. A Data 360 rollout that starts with one honest use case compounds. One that starts with "connect everything" usually stalls in the identity rules.
The agent is the part everyone demos. The data layer is the part that decides whether the demo survives your org. Do the boring work first.
Good to know
What is Salesforce Data Cloud, now called Data 360?
It is Salesforce's data layer: it pulls records from your CRM orgs, warehouses, apps, and event streams, resolves them into unified profiles, and makes that unified data available to Flow, segmentation, analytics, and Agentforce. Data 360 is the newer name for the same platform.
Do I need Data 360 to use Agentforce?
Agentforce can run against a single org's records without it. Once an agent needs context that lives outside that org, or your org is full of duplicates, a unified and governed data layer stops being optional. In practice that layer is Data 360 or something you build to do the same job.
Is Data 360 a replacement for a data warehouse?
No. It sits alongside one. Zero-copy connectors let it read from warehouses like Snowflake or BigQuery without moving everything, so the warehouse stays the analytical system of record and Data 360 becomes the activation layer the CRM and agents use.
What should we do before buying it?
Inventory where customer data actually lives, decide which system wins for each field, and pick one use case with a measurable outcome. If you cannot answer those three, the licence will not answer them for you.
We engineer ideas into working software.
Tarka · logic · Shila · stone