Salesforce sits Data 360 underneath several Agentforce capabilities, so the advice you’ll hear is that Data 360 comes first. That advice is accurate and close to useless, because “Data 360 first” describes 2 very different projects.
One is a provisioning step an admin finishes in an afternoon. The other is a customer-data architecture program with source connections, a data model, identity resolution and a budget attached.
Plenty of teams get quoted for the second when their pilot only needs the first.
One naming note before we start. Data 360 is the current name for what Salesforce used to call Data Cloud, so if you’ve been searching whether Agentforce requires Data Cloud, or reading older Agentforce Data Cloud guidance, it’s the same product. This page uses the current name throughout.
This page separates them. You’ll get the current Salesforce requirement in Salesforce’s own words, the signals that justify deeper Data 360 work, and a way to size the data architecture against the agent you’re actually building.
TL;DR
Salesforce requires Data 360 to be provisioned and enabled in your org before Agentforce runs. That requirement is a platform switch, and for most orgs it costs nothing. How much Data 360 you build on top of that switch depends entirely on what your first agent needs to know.
- Data 360 must be provisioned and enabled for Agentforce, and Enterprise Edition and above get that provisioning at no cost.
- A full Data 360 implementation is a separate decision driven by the agent’s data requirements.
- Agentforce Data Library is built on Data 360 and consumes Data 360 credits.
- Multi-system identity, real-time context, zero-copy warehouse access and advanced retrieval are the 4 signals that justify a deeper build.
Do You Need Salesforce Data 360 Before Agentforce?
Yes for provisioning, and it depends for everything after that.
Salesforce’s Considerations for Agentforce Projects page is unambiguous: “To use Agentforce, these products and features must be enabled in your Salesforce org: Lightning Experience, Einstein Generative AI, Data 360, Einstein Bots.” Data 360 sits in that list alongside Lightning Experience, which tells you what kind of requirement it is.
So the answer to the headline question is yes. Data 360 has to be on.
The budget conversation turns on what your edition already includes. Salesforce documents free Data 360 provisioning for Enterprise Edition and above, and it includes 250,000 Data Services credits, 1 TB of storage, 1 Data 360 admin, 100 internal identity users and 20,000 permission set licenses. Unlimited Plus customers get 2,500,000 credits instead.
Professional Edition, Government Cloud, and orgs that already hold a Data 360 or CDP license fall outside that offer. If you’re on Professional Edition, the requirement carries a real purchase behind it, and that changes your sequencing.
For everyone else, the useful question is how much Salesforce Data 360 for Agentforce you have to build on top of a switch you already hold.
Two separate questions hide inside the headline one. The platform question is whether Data 360 is available and enabled in your org. The project question is whether your first use case needs unified profiles, real-time data, multi-source retrieval, zero-copy access or identity resolution.
The first has one answer for everybody. The second changes with every agent you build, and the rest of this page is about answering it.
|
Agent use case |
Data 360 enabled |
Deeper Data 360 implementation |
|---|---|---|
|
CRM records plus existing Flow or Apex |
Required |
Usually limited |
|
Knowledge or files through Data Library |
Required |
Targeted setup |
|
Multi-system customer profile |
Required |
Strong case |
|
Real-time or zero-copy data |
Required |
Strong case |
|
Advanced multi-source retrieval |
Required |
Strong case |
Data 360 Enabled vs Data 360 Implemented
These 2 words get used interchangeably in Agentforce advice, and the distance between them is measured in months and budget. Each half covers something different, and the difference is worth stating precisely.
Enabled means Data 360 is provisioned and switched on. Salesforce’s Trailhead guidance on Data 360 and Agentforce puts it plainly: Data 360 must be provisioned and enabled for all Agentforce use. At this level, Agentforce platform services that depend on Data 360 can run, which covers Agentforce Data Library, Agentforce Analytics, Einstein Trust Layer functions, and the generative AI audit and feedback records your compliance team will eventually ask about.
The Agentforce Developer Guide gives the setup order: provision Data 360, enable Einstein generative AI, configure the Einstein Trust Layer, then add agents. Data 360, in Salesforce’s words, “is required to ensure that the Einstein Trust Layer functions correctly and protects your data.”
Implemented means you’ve built something on it. Connecting sources, modeling data, running transformations, resolving identities, assembling unified profiles, wiring zero-copy federation and configuring retrieval are all implementation work, and each one carries effort and consumption.
|
Enabled |
Implemented |
|---|---|
|
Platform prerequisite |
Data architecture project |
|
Provisioning switch |
Source design and connection |
|
Base Agentforce support |
Cross-system customer context |
|
Admin setup, hours |
Identity, retrieval, activation |
|
No implementation decisions |
Scoped against specific use cases |
The vocabulary matters because vendors and blogs use “Data 360 required” to mean both. When someone tells you Agentforce needs Data 360, the useful follow-up is which of these 2 they mean.
If the rename itself is still causing confusion in your org, the shift from Data Cloud to Data 360 is covered in how Salesforce Data Cloud evolves into Data 360.
Start With the Agentforce Use Case, Then Decide the Data 360 Scope
Most teams scope Salesforce Data 360 for Agentforce backwards. They pick a Data 360 SKU, work out what to build with it, and end up designing the agent around the platform instead of the job.
Salesforce’s own implementation guidance runs the other way. It asks what data you need, where that data lives, and whether it has quality problems, before anything gets connected.
Run the agent through the same questions:
- What job does this agent perform, in one sentence?
- Which Salesforce records does it read or write?
- Does it need Knowledge articles or uploaded documents?
- Does it need to reach an external system, and to read or to act?
- Does it need information from several systems at once?
- How fresh does that information have to be?
- Does it need to recognize the same customer across systems?
- Does it need semantic retrieval, or will a record lookup do?
- Does any of that data have to stay where it is?
The answers resolve into a dependency chain, and each link narrows the architecture:
Agent job → information required → source location → freshness → identity need → retrieval method → Data 360 scope
Work it in that order and the Data 360 scope falls out of the requirements rather than getting picked first. Work it backwards and you’ll build a customer-data program to support an agent that reads 3 fields off a Case.
Each link in that chain has a threshold, and crossing one moves the answer a step closer to implementation. The Agentforce Readiness Assessment puts the same questions to an org’s actual records, Knowledge articles and connected systems, and reports where each dependency currently sits.
When Salesforce CRM Records and Existing Automation May Be Enough
The lightest architecture on this page is also the most common first agent, and it needs very little Data 360 work beyond the provisioning switch.
The most common first agent looks up a Case, reads an Account field, calls an existing autolaunched Flow, updates a record and reports back. Everything it touches already lives in Salesforce, and the business logic already exists as automation somebody wrote and tested.
The path looks like this:
Agentforce → Salesforce record → Flow or Apex action → result
Nothing in that chain requires unified profiles, identity resolution rules or a data model. Data 360 stays switched on because the platform requires it, and the project spends no sprint on ingestion.
Agents that fit this pattern include account and case lookups, opportunity summaries, field updates against defined rules, routine approvals, and any service operation a Flow already handles.
Before you commit to this scope, check 5 things:
- Are all the records the agent needs already in Salesforce?
- Are those records reliable enough to answer a customer with?
- Can existing Flow or Apex complete the business action end to end?
- Does the agent need context beyond those records to answer well?
- Does the process require matching the same person across systems?
3 yeses and a no on the last 2 means you’re in the light lane.
The boundary sits exactly where the agent’s context runs past what Salesforce already holds reliably. For a fuller picture of how agents reason over the records and actions available to them, see how Agentforce works.
When Agentforce Data Library Is Enough for the First Use Case
The moment an agent needs to answer from a document instead of a record, the conversation changes. And this is where most teams assume a customer-data program is about to land on them.
Agentforce Data Library is the path that avoids it. Salesforce states the dependency directly: “To use Agentforce Data Libraries, you must have Data 360 set up,” and “Data libraries consume Data 360 credits.” So the library sits on Data 360, and it builds the underlying components for you: the data stream, data lake object, data model object, search index and retriever. Assembling those by hand is the work a library removes.
Current libraries support 3 source types: Salesforce Knowledge, files you upload, and custom retrievers that reach further into Data 360.
Policy assistant. An agent answers employee or customer questions from a set of approved policy documents you upload once and maintain deliberately.
Service knowledge agent. An agent answers from Salesforce Knowledge your team already curates, which means the grounding quality tracks the article quality you’re already managing.
Focused document retrieval. An agent works across a bounded collection of product manuals, contracts or specifications where the corpus is known and stable.
Internal knowledge assistant. An agent retrieves from curated internal content for staff, which lowers the risk of a wrong answer reaching someone outside the company.
4 limitations belong in the plan before you build:
A library can’t support multiple data sources simultaneously, and the source type can’t be changed after the library is created. That’s a decision you make once, so make it against the corpus you expect in 12 months rather than the one you have today.
Web search isn’t supported for new data libraries, and existing web-search libraries are read-only. For agent web search, Salesforce now points to the Search the Web standard action instead.
Data Library doesn’t support companion orgs through Data Cloud One. Multi-org estates need a custom retriever to reach across, which pushes that scenario into implementation work.
And consumption starts with the first query. Retrieval convenience and retrieval consumption arrive together, which is why the cost layers further on treat them as one line.
Data Library gives a team real retrieval capability without a customer-data unification program attached. For how the library sits among the other Agentforce components, see Agentforce 360 explained.
External API Access vs Data 360 Integration
A shortcut circulates in Agentforce advice: if the data sits outside Salesforce, you need Data 360. It’s too broad, and following it inflates scope on projects that don’t need it.
Salesforce supports custom agent actions built on External Services. Register an OpenAPI schema, and the operations in it become available as agent actions.
Flow, Apex callouts and MuleSoft APIs offer the same reach, and none of those routes asks for a Data 360 data model.
So split the requirement in 2.
Transactional access covers checking a shipment status, retrieving a current balance, creating a ticket in an external system, or updating an external order. One system, one call. The path is Agentforce → Flow, Apex, MuleSoft or External Service → external system.
Cross-system context covers combining billing, service, commerce and CRM information into a picture, recognizing one customer across those sources, or retrieving semantically across several repositories. That’s a data problem, and it’s where Data 360 earns its keep.
One caveat on editions. External Services custom agent actions run in Enterprise, Performance, Unlimited and Developer editions. On Professional Edition, the lighter alternative isn’t available, which narrows your options before the data question even comes up.
|
Requirement |
Direct action or API |
Data 360 implementation |
|---|---|---|
|
One transactional lookup |
Strong candidate |
Optional |
|
Write to an external system |
Strong candidate |
Separate data need |
|
Unified cross-system context |
Limited |
Strong candidate |
|
Identity reconciliation |
Limited |
Strong candidate |
|
Reusable context across several agents |
Limited |
Strong candidate |
Connecting agents to systems is a different discipline from unifying data about customers, and the 2 get scoped separately. Agentforce integration services cover the first of them: action design, authentication, error handling and the API contracts an agent ends up depending on.
Broader system-to-system work, where the agent is one consumer among several and the connection has to serve reporting and downstream processes too, sits with Salesforce integration services.
When Identity Resolution and Unified Customer Profiles Become Necessary
One scenario turns a light project into a real one.
The same person exists as a Salesforce Account, an ecommerce login, a billing customer number, a product telemetry ID and a support contact. 5 records, 5 identifiers, 1 human being. Your agent gets asked a question that spans them.
Without reconciliation, the agent answers from whichever fragment it reached first. That produces confident wrong answers, which is the failure mode that damages trust in an agent program fastest.
Data 360 identity resolution addresses this with matching rules, reconciliation logic and unified profiles that harmonize attributes across sources. Once built, that context is reusable, so the second and third agents inherit it rather than rebuilding it.
Salesforce’s implementation sequence puts identity resolution after ingestion, transformation and mapping, which tells you something useful about effort. It sits at step 7 of that sequence, and the 6 steps before it (provisioning, user setup, source identification, ingestion, transformation and mapping) are all prerequisites.
Work through 3 questions before committing:
One identity or several? Can your existing systems already identify the same customer reliably, or does each one hold its own version? The honest answer is usually visible in how support staff currently look a customer up across screens.
Shared key or matching logic? A consistent customer ID across systems makes this a connection problem. No shared key makes it a probabilistic matching problem, and those are meaningfully harder to get right.
Which profile should the agent trust? If one system is already authoritative for the attributes the agent needs, pointing the agent at that system beats unifying 5 of them. Authority runs per attribute rather than per system, so the answer can differ for billing address and for entitlement status.
Answer those with the org you have rather than the org you want, and the scope often shrinks below what the first architecture sketch assumed. Plenty of agents need 1 authoritative source and a written rule about which system that is.
Real-Time and Zero-Copy Data Can Change the Answer
2 requirements push hardest toward a deeper build, and they interact in a way that catches architects out.
Freshness. An agent quoting order state, inventory levels, live transaction status, product usage or session behavior is working with data that changes while the conversation happens. A stale answer about a policy is awkward. A stale answer about whether an order shipped is a support ticket.
Real-time context is one of the capabilities a deeper Data 360 architecture provides, and it’s the layer Salesforce real-time data access services deal with: streaming ingestion, refresh intervals, and the governance that decides which data is allowed to move at that speed.
Data that should stay put. Where trusted data already lives in Snowflake, Databricks, BigQuery, Redshift, Amazon S3 or Iceberg tables, zero-copy federation makes it queryable through Data 360 without duplicating the source.
Salesforce’s Data 360 interoperability decision guide splits zero copy into 3 methods, and the difference between them is the whole point.
|
Method |
How it behaves |
Best fit |
|---|---|---|
|
Live Query |
Queries the external system directly, schema-on-read, no duplication |
Freshness-critical context |
|
Caching |
Local cache refreshed on a configurable interval, 15 minutes to 7 days |
Frequently repeated queries |
|
File Federation |
Reaches large datasets in object stores |
Batch and analytical workloads |
Salesforce’s zero copy data federation supportability documentation is blunt about the limits. Zero copy doesn’t support near real time identity resolution, and it doesn’t support streaming data transforms.
So an agent that needs identity-resolved context in real time can’t get there by leaving the data in the warehouse. Freshness and cross-system identity pull against each other here, and the use case has to declare which of the 2 it actually demands before the architecture can settle.
Salesforce’s rule for the ingest-or-federate decision is worth borrowing. Ingest when you need an auditable, centralized copy with controlled access and lineage. Federate when the data belongs at its source and freshness outranks central governance.
The question that settles it: does the agent need governed context from enterprise data that should remain in its current platform? A yes makes zero copy part of the architecture rather than a later optimization.
The architecture behind that choice is covered in zero-copy data and Data 360.
When Advanced RAG Needs a Deeper Data 360 Implementation
Retrieval in Agentforce runs at 2 levels, and knowing which one your use case needs saves a lot of unnecessary architecture.
Quick-start retrieval is the Data Library path described earlier: 1 source, retrieval components built for you, and a configuration screen in place of an architecture. It handles a known corpus well, and it stops being enough the moment the corpus stops being known.
Advanced retrieval is a configured Data 360 stack, and Salesforce documents the full path:
data stream → data lake object → data model object → hybrid search index → custom retriever → prompt template → agent action → agent with subagent
That’s 8 components against a library’s 1 configuration screen, and the payoff is control. You get data cleansing at the data lake object layer, several sources mapped to a single data model object, custom filtering and field selection in the retriever, component-level testing, and the ability to tune search strategy between hybrid and vector approaches.
That last tradeoff is the clearest signal you’ve outgrown a library. If your team can’t articulate why hybrid search would beat vector search for your corpus, the advanced path is premature.
Data graphs sit at the top of this range. A data graph pulls structured data from your data model objects into a precomputed, read-only JSON record, so queries return almost instantly instead of assembling relationships on demand. It’s what makes real-time identity resolution, real-time calculated insights and real-time segmentation work, which is why data graphs turn up in real-time architectures and rarely in batch ones. The shape is a chain, customer profile → orders → products → service history, assembled once and read as a unit. Salesforce’s guidance on grounding agents with Data 360 covers where that sits among the other grounding options.
Grounding prompt templates with data graphs carries real constraints, and they’re worth knowing before you design around them.
Only data graphs associated with the object inputs in the template are supported. Prompt Builder handles whole data graphs and not subgraphs. And the data model object has to be the graph’s root or connect to a Unified Profile data model object at the root.
Those limits decide whether a data graph fits your agent’s context shape. Check them against the design while the design is still changeable.
What Does Data 360 Add to Agentforce Cost?
The reason “do you need Data 360 first” gets asked at all is that people hear it as “do you need to fund a second project first.” So separate the money into 4 layers, because they behave differently.
Entitlement. Start with what you already hold, which for Enterprise Edition and above is the free provisioning described earlier. The practical question is which part of that allowance runs out first.
Storage and identity users rarely bind on a pilot. Credits do, and unstructured processing consumes them far faster than record queries, so a document-grounded agent reaches the ceiling well before a record-reading one. Professional Edition orgs have no floor at all and start the arithmetic from a purchase.
Usage. Salesforce’s Data 360 pricing lists 3 models: Flex Credits at $500 per 100,000 credits, Profiles at $240 per 1,000 profiles per year, and Enterprise Profiles at $420 per 1,000 profiles per year. Bringing data into Data 360 is free. You pay when you use it.
Billable activity covers processing unstructured data, prep and harmonization and unification, segmentation and activation, queries and sharing, and streaming and real-time work. Profile-based pricing bundles some of those into the flat rate while Flex Credits charge per usage, so the model you’re on changes which agent designs cost more.
For Data Library specifically, Salesforce’s billing documentation says that if your contract includes Data Service Credits, those are consumed for all Data 360 usage, and running out puts your org on its Data Service Credit overage rate for the rest of the term. Orgs contracted on Flex Credits consume those instead. 4 usage types apply: data queries, intelligent processing, unstructured data processing, and storage above your allocation.
Implementation effort. This scales with source count, data modeling depth, identity resolution complexity, zero-copy design, governance requirements and retrieval sophistication. An agent reading Salesforce records carries almost none of it. A unified profile across 5 systems carries a lot, and the gap between those 2 is the largest single variable in any Data 360 quote you receive.
Agentforce usage. Agent actions carry their own consumption, metered separately from Data 360 and drawn against a different allowance. Keep the 2 as separate budget lines, because they scale on different drivers: Agentforce usage tracks conversation and action volume while Data 360 usage tracks data volume and refresh frequency.
A workable shape for the budget:
Agentforce + Data 360 budget = Agentforce usage + Data 360 usage + implementation work + ongoing operations
One warning about published figures. Salesforce Foundations is a $0 add-on, and its own page currently gives 2 different included-credit numbers in 2 different sections. Confirm the current figure with your account team rather than trusting any number you read, including on Salesforce’s site.
Each of those 4 layers is estimated on different inputs, which is why a single Data 360 number tends to be wrong in both directions at once. AI readiness consulting covers how the layers get sized against a named use case instead of against an org as a whole.
Check Data Quality Before Expanding the Data 360 Architecture
Implementing Data 360 does not repair bad source data. Connecting unreliable records to a larger platform gives you unreliable records at greater scale, with more places to notice them.
Audit only the data the first agent actually touches. A full org audit is a different project and it delays the one you’re trying to start.
|
Data issue |
Evidence to inspect |
Why Agentforce cares |
|---|---|---|
|
Duplicate records |
Duplicate report on the target objects |
The agent answers from whichever record it reaches |
|
Missing fields |
Completeness report on required fields |
Actions fail or run on partial input |
|
Stale records |
Last-modified age distribution |
The agent states outdated facts confidently |
|
Conflicting Knowledge |
Content review of the article set |
Retrieval returns 2 answers and picks 1 |
|
Unclear ownership |
Source map per attribute |
No defined source of truth to ground against |
|
Inconsistent identifiers |
Key comparison across systems |
Identity matching gets harder and less certain |
Work the table against the records, Knowledge articles and external sources on your agent’s list. Anything that fails here fails louder once an agent is speaking to a customer with it.
Salesforce’s implementation guidance asks the same question before connecting anything: does the data have quality issues, what type, and how widespread. Run that check while the architecture is still open.
Several rows in that table trace back to one root cause, which is that no attribute has a named owner. Salesforce data governance services cover that layer, from ownership assignment through to the field-level standards that stop the same problems reappearing a quarter later.
Can You Start Agentforce First and Expand Data 360 Later?
Usually yes, and the phasing is the part worth getting right.
Phase 1: a bounded first agent. Use existing Salesforce records, existing Flow and Apex actions, and only the retrieval the first job requires. Data 360 stays enabled because it has to be, and the implementation work stays close to zero. The goal is a working agent and real usage data to size the next phase with.
Phase 2: targeted Data 360 use. Add a Data Library for Knowledge or documents, connect a specific external source, or build a custom retriever where the corpus outgrows a single library. Each addition answers a requirement the first phase surfaced.
Phase 3: the broader architecture. Identity resolution, unified profiles, zero-copy federation, real-time context, advanced retrieval and reusable context shared across several agents. This is the phase that deserves the word “implementation.” It also pays back across agents instead of within one, so the business case changes shape here.
Now the caveat, because phasing has a failure mode. Choices made in phase 1 can make phase 3 harder. If you know a unified customer profile is coming in 6 months, decisions about data model objects and source connections should anticipate it, even while the first agent doesn’t use them.
A narrow pilot should still be planned against the dependencies you expect. Map the ones coming within the year, then build only the ones the current agent requires.
The sequencing tradeoffs are worked through in more depth in this Agentforce implementation guide.
VALiNTRY360 Data 360 Dependency Check
Run the first agent through these 10 questions. Answers in the left column point toward a lighter scope. Answers in the right column are the signals that justify a deeper Data 360 implementation.
|
Question |
Lower Data 360 scope |
Stronger implementation signal |
|---|---|---|
|
Are the required records already in Salesforce? |
Yes |
No, they live elsewhere |
|
Is one source enough to answer well? |
Yes |
Several systems contribute |
|
Does the agent only need an external transaction? |
An action or API may fit |
Cross-system context is needed |
|
Does it need Knowledge or files? |
Data Library handles it |
Advanced retrieval is required |
|
Does it need identity matching across systems? |
No |
Yes |
|
How fresh must the data be? |
Daily or on request |
Real-time or near real-time |
|
Must warehouse data stay where it is? |
No |
Zero-copy federation applies |
|
Does it retrieve from several sources at once? |
No |
Custom or ensemble retrieval |
|
Does data quality already meet the use case? |
Yes |
Remediation comes first |
|
Will future agents reuse this context? |
Unlikely |
A shared Data 360 layer pays off |
Mostly left column means your first agent needs Data 360 enabled and very little else, which is the lightest Salesforce Data 360 for Agentforce footprint available. Mostly right column means the data work is the project and the agent is the outcome, which is a different plan and a different budget.
Answers that split across both columns are the common case. A split usually means 1 requirement is driving the whole architecture, and naming that requirement keeps the build proportionate to the agent instead of proportionate to the platform.
A result that lands 8 left and 2 right is the common shape, and it’s worth reading closely. Those 2 right-column answers are the architecture, and the other 8 are scope you can safely leave out of the first build.
The Salesforce AI solutions practice describes where Data 360 sits among the other platform decisions an AI program makes, from grounding strategy through to monitoring.
Salesforce Data Foundation Case Studies Worth Reading
If you want to see what these decisions look like once they’re built, the projects below are published in full on the VALiNTRY360 case studies library. Each one maps to a factor this page weighs.
1. AdventHealth University: A Full 360 View of Every Alumnus
AdventHealth University held 25 years of alumni records spread across disconnected systems that could store information without making it usable. Contact details, giving history and continuing education activity couldn’t be acted on across the 4 functions that needed them: alumni relations, fundraising, continuing education and accreditation reporting. VALiNTRY360 ran a full ETL migration of the 25-year record set and rebuilt it around relationship management, producing a full 360 view of each alumnus after graduation.
Key takeaway: A unified profile earns its cost when several functions need the same entity assembled from sources that were never designed to agree, which is the exact condition that justifies Data 360 identity resolution for an agent.
Read the full case study: AdventHealth University Salesforce Implementation
2. Real California Milk: 500 Annual Data Hours Cut to 4
Real California Milk was running on SugarCRM with staff manually updating and reconciling account and contact records, reporting that was hard to produce, and stakeholders who didn’t trust the numbers. The organization was migrated to Sales Cloud with an ETL layer built for quarterly imports and reconciliation, alongside MailChimp and Zoom connections for activity capture. Annual labor hours spent manually updating data fell from 500 to 4.
Key takeaway: Establishing a single source of truth is a data project with its own return, separate from anything built on top of it, and it’s the work that has to land before an agent can be trusted to answer from those records.
Read the full case study: Real California Milk Salesforce Migration
3. BIC Graphic: Handle Time Down 7 Minutes Across 4 Teams
BIC Graphic sold promotional products at scale with no CRM, which left field sales, inside sales, quoting and customer service working from siloed data and handing customers between them. VALiNTRY360 deployed Sales Cloud and Service Cloud with a Sales Performance System and a full connection to the existing ERP, giving all 4 teams one customer record. Average handle time fell by 7 minutes and new pipeline opportunities increased by more than 27%.
Key takeaway: Cross-system context and single-system transaction access solve different problems, and a project reaching an ERP for shared customer state sits on the implementation side of the Data 360 decision rather than the action side.
Read the full case study: BIC Graphic Salesforce Sales Cloud Case Study
4. Tri-County Hearing Services: 7 Patient Touchpoints in 60 Days
Tri-County Hearing Services relied on staff memory for patient follow-up, so prospective patients who called about a hearing test often weren’t contacted again. A customized Health Cloud implementation was delivered through the Quick Start program, layered with High Velocity Sales cadences, automatic lead assignment to Care Coordinators and reporting built around practice-specific fields. The practice reached 7 touchpoints with each patient within 60 days without significant programming.
Key takeaway: Systematic action depends on records being complete and consistently structured first, which is why the data quality audit belongs ahead of the architecture decision rather than after it.
Read the full case study: Tri-County Hearing Services Health Cloud Implementation
5. All American Solar: 16% Quarterly Growth From a Bounded Scope
All American Solar needed a CRM it could maintain without a dedicated administrator, plus unified reporting on sales progress, installation updates and ROI. A Sales Cloud Quick Start covered lead and opportunity processes, custom fields across the core objects, record types and roles for access control, bidirectional Gmail synchronization and standard dashboards, with 4 hours of on-site training. The company recorded 16% quarterly growth year over year.
Key takeaway: A deliberately narrow first scope produces usage data that sizes the next phase, which is the same argument for launching an agent on existing records before committing to a broader Data 360 build.
Read the full case study: All American Solar Sales Cloud Implementation
FAQs About Salesforce Data 360 and Agentforce
Does Agentforce require Salesforce Data 360?
Yes. Salesforce’s Considerations for Agentforce Projects page lists Data 360 among the products that must be enabled in your org to use Agentforce, alongside Lightning Experience, Einstein Generative AI and Einstein Bots. That requirement covers provisioning and enablement, which is a much smaller job than a completed data project.
Do I need to implement Data 360 before my first Agentforce agent?
Usually not. Provisioning is required, and Enterprise Edition and above get it at no cost. Whether you need to build on top of it depends on whether the agent’s context extends past the records Salesforce already holds reliably.
What is the difference between enabling and implementing Data 360?
Enabling means Data 360 is provisioned and switched on, which takes an admin hours and turns on the Agentforce services that depend on it. Implementing means connecting sources, modeling data, resolving identities and configuring retrieval, which is a scoped project with effort and consumption behind it.
Can Agentforce use Salesforce CRM records without a full Data 360 implementation?
Yes. An agent can read and write Salesforce records and call existing Flow or Apex actions without unified profiles, identity resolution or a Data 360 data model. Data 360 stays enabled underneath because the platform requires it.
Does Agentforce Data Library require Data 360?
Yes. Salesforce states that you must have Data 360 set up to use Agentforce Data Libraries, and that data libraries consume Data 360 credits. The library builds its retrieval components on top of Data 360.
Do I need Data 360 to use Salesforce Knowledge with Agentforce?
You need Data 360 enabled, and a Data Library sourced from Salesforce Knowledge handles the retrieval. That path avoids a broad customer-data unification project while still consuming Data 360 credits for processing and queries.
When does Agentforce need identity resolution?
When the same customer exists under different identifiers across systems and the agent has to answer questions that span them. If one system is already authoritative for the attributes the agent needs, pointing it there usually beats unifying several sources.
Does Agentforce need Data 360 for external systems?
Only when the requirement is unifying or retrieving across systems. Reaching a single external system to look something up or perform a transaction can run through External Services, Flow, Apex or MuleSoft without a Data 360 data model.
Can Agentforce call an external API without a full Data 360 implementation?
Yes. Registering an OpenAPI schema through External Services makes those operations available as custom agent actions. Note that this route runs in Enterprise, Performance, Unlimited and Developer editions only.
When does Agentforce need zero-copy data?
When trusted data already sits in a platform such as Snowflake, Databricks, BigQuery or Redshift and should stay there. Salesforce offers 3 federation methods, and one of them caches on an interval configurable up to 7 days, so check the method against your freshness requirement.
Does Data 360 improve Agentforce RAG?
It can, substantially. A configured Data 360 stack supports several sources mapped to one data model object, custom and ensemble retrievers, hybrid or vector search tuning, and data graphs. A Data Library gives you none of that control and needs far less work.
How much does Data 360 add to Agentforce cost?
That depends on which Data 360 functions your agent actually uses. Flex Credits run $500 per 100,000 credits, profiles run $240 or $420 per 1,000 per year depending on tier, and ingestion is free. Enterprise Edition and above start with 250,000 Data Services credits at no cost.
Can I expand Data 360 after launching an Agentforce pilot?
In most cases yes, and phasing is sensible. Plan for the dependencies you expect within the next year, though, because data model and source decisions made in a narrow pilot can make a later unified profile harder to build.
Does Data 360 fix poor Salesforce data quality?
No. Connecting unreliable records to a larger platform gives you the same problems at greater scale. Audit duplicates, completeness, staleness, Knowledge conflicts and ownership for the data your first agent touches before expanding the architecture.
What should I check before deciding how much Data 360 Agentforce needs?
Define the agent’s job, list the records and content it needs, locate each source, set the freshness requirement, decide whether identity matching is necessary, then choose the retrieval method. The Data 360 scope falls out of those answers.