iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Salesforce positions Data 360 as a shared data and context foundation that lets AI agents retrieve enterprise evidence, apply access rules, and carry approved memory across sessions and agent experiences. It is designed to connect existing data—not require every source to be moved into one store—while an Enterprise AI Harness links that context to governed actions. Whether it works well for a particular organization depends on its data, permissions, retrieval setup, and operating controls.
What Salesforce Data 360 does for enterprise AI
An AI model’s context window can hold information for a task, but it does not by itself provide a reliable way to discover current company data, decide which evidence a user may access, or preserve approved knowledge between sessions. Salesforce describes Data 360 as a platform layer for bringing those capabilities together across Salesforce applications, external data platforms, operational systems, documents, and knowledge bases.
The architecture is not simply a central repository. Data can be ingested, or it can remain in an existing system and participate through Zero Copy federation. Salesforce Architects’ Data 360 Architecture describes platform components for connectivity and federation, storage and compute, processing and intelligence, trust controls, unified query and retrieval, and context assembly. The Enterprise AI Harness is the layer Salesforce describes as connecting context to governed action.
Free tools Windows power users keep installed
One-click scans. No signup required.
That distinction matters: context is not trustworthy merely because an agent can access more information. It must be relevant to the question, current enough for the task, tied to its source, and available under the correct identity and policy.
#1 Best Overall
How enterprise data becomes retrievable context
For documents and other unstructured content, Salesforce Help’s Retrieve Data describes a pipeline that prepares content for search and makes selected results available to prompts, flows, or agents.
- Load and prepare content. Content is loaded, divided into chunks, and vectorized, then placed in a search index. Chunking and indexing choices affect what evidence can be found and returned.
- Search for task-relevant evidence. A retriever searches an index for a particular use case. Salesforce’s architecture guide describes keyword, vector, and hybrid indexing and search, as well as queries across structured and unstructured data.
- Apply filters and policy. A retriever can narrow results by such criteria as category, recency, or geography. Salesforce Help says retrievers follow configured data governance policies and perform row-level access checks.
- Pass results into the application. Relevant results can be supplied to prompt templates, flows, or agents. The Help guidance also describes citation support that can point a generated response back to source content for checking.
These mechanisms provide a route from enterprise content to agent context; they do not guarantee that retrieval will be accurate. Results depend on source quality, schemas, chunking, indexing, filters, permissions, and implementation. A technically successful search can still return incomplete or unsuitable evidence if those choices do not fit the task.
How Data 360 distinguishes context from memory
Salesforce Engineering separates agent state into three categories. The distinction helps prevent a conversation transcript or an unverified outcome from silently becoming durable organizational knowledge.
| Type | What it contains | How to think about it |
|---|---|---|
| Working context | The current reasoning step’s plan, evidence, tool state, and unresolved decisions. | Immediate material needed to complete the current step. |
| Short-term memory | An active trace across turns, including events, tool calls, decisions, actions, and outcomes. | Continuity during an ongoing interaction or task. |
| Long-term memory | Approved facts, preferences, commitments, relationships, and prior work that remain useful beyond a session and belong to the enterprise. | Durable knowledge that should be retained only under an intentional approval and governance process. |
Salesforce Engineering summarizes the boundary this way: “A transcript records what happened; it does not automatically become enterprise memory.” In practice, an organization needs to determine what qualifies for long-term memory, who can approve it, how it is corrected or retired, and which agents and channels may use it. The described architecture supports memory that persists across agents and channels, but it does not mean every interaction should be retained as enterprise knowledge.
How identity and governance are meant to follow the context
Salesforce’s Data 360 Security Architecture describes a shared-responsibility model: Salesforce secures and maintains the platform, while customers remain responsible for their data, configuration, and operating processes. It describes policy decision and enforcement components that apply access rules across APIs, the user interface, CRM enrichment, and retrieval-augmented generation (RAG) retrieval.
For an enterprise deployment, the critical question is whether a user’s identity and permissions remain valid across the whole path: source data, indexing or federation, retrieval, generated response, and any action an agent takes. Row-level checks in retrieval are one control, not a substitute for validating field-level access, consent, policy configuration, and authorization at action time. The security description establishes Salesforce’s intended control model; customers still need to configure and verify it against their own access rules and processes.
Salesforce describes the Enterprise AI Harness and context layer as spanning Salesforce, custom, partner, and external agent experiences while carrying identity, provenance, and governance. That is an architectural aim rather than proof that every integration automatically preserves those properties. Teams should verify what identity is passed, how source provenance is exposed, and whether restrictions survive each handoff into a tool or downstream action.
Recommended Free Tools
What Salesforce reports about scale and latency
In its Q2 FY27 article, Salesforce reports the production-volume figures below. They are company-reported platform totals, not independently validated measures of retrieval quality or business outcomes.
| Measure | Salesforce-reported figure | Qualification |
|---|---|---|
| Connected records | 104.3 trillion, including 81.5 trillion Zero Copy rows | Salesforce-reported Q2 FY27 figure. |
| Records processed and query records | 12.7 quadrillion processed; 9.7 quadrillion query records | Salesforce-reported Q2 FY27 figures. |
| Unstructured data and unified profiles | 22 terabytes of unstructured data; 25.3 billion unified profiles | Salesforce-reported Q2 FY27 figures. |
| Activated records and action events | 2 trillion activated records; 41 billion action events | Salesforce-reported Q2 FY27 figures. |
Salesforce also reports two latency results for different workload types. They should not be read as one benchmark or as a service guarantee.
| Workload Salesforce describes | Reported latency | What the figure does and does not establish |
|---|---|---|
| Production Agentic RAG using semantic plus keyword search across structured and unstructured data | 126 milliseconds p50; 352 milliseconds p90 | Salesforce-reported Q2 FY27 article result for this production workload. |
| Separate high-concurrency query test | Approximately 40 milliseconds median at approximately 750 queries per second | Salesforce-reported Q2 FY27 article result for a distinct test workload. |
The latency figures are complementary evidence about different workloads, not directly comparable measurements. Neither establishes the performance an organization will get with its own data, policies, queries, concurrency, and integrations. No independent benchmark or neutral comparison is established by the cited Salesforce material.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How to evaluate Data 360 for a real deployment
Assess the design against the work your agents must do, rather than treating “trusted context” as a single feature. A pilot should use representative data, permissions, and query patterns.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
- Data authority and movement: Identify which systems remain authoritative and which sources will be ingested versus federated through Zero Copy. Check the operational implications of each choice, including how source changes become available to retrieval.
- Coverage and semantics: Confirm that the required structured records and unstructured formats can be modeled and searched for the actual task. Test whether field meanings, relationships, and business terminology are represented well enough for useful queries.
- Retrieval relevance: Evaluate chunking, keyword and vector search, hybrid retrieval, filters, and any reranking used in the implementation. Use domain-specific questions and inspect both relevant results and important omissions.
- Access controls: Test representative identities and edge cases across retrieval and action paths. Verify row- and field-level permissions, consent, policy decisions, and whether an agent can pass restricted information to a tool or action.
- Freshness: Measure how quickly source updates reach the available retrieval path. Decide whether recency filters or streaming paths are sufficient for the use case.
- Memory lifecycle: Define who approves durable facts, how incorrect or outdated memories are revised, and how raw transcripts or unverified outcomes are prevented from becoming long-term enterprise memory.
- Portability and observability: Check how identity, provenance, context, and outcomes travel among Salesforce, custom, partner, and external agents. Ensure operators can inspect the evidence and actions behind consequential results.
- Performance under representative load: Measure retrieval latency and concurrency with the organization’s own data and policies. Test SQL and graph queries separately where relevant rather than assuming one workload’s result predicts another’s.
Salesforce Architects states that “Data 360 does not replace existing enterprise investments.” The architecture is presented as a way to make existing data actionable through Salesforce, not as a requirement to replace other data platforms. Whether federation, ingestion, or a mix is suitable depends on the systems involved and the workload being built.
What the available evidence supports
Salesforce’s product guidance and architecture descriptions explain how Data 360 is intended to connect distributed data, retrieval, governance, context, and agent action. The Q2 FY27 figures are Salesforce-reported scale and workload measurements. They do not independently establish that a particular deployment will retrieve the right evidence, enforce every organization’s policies correctly, or improve customer outcomes. Those are implementation questions to validate using the organization’s own data and controls.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
