Skip to main content

Agentforce retrievers: grounding inside the Salesforce platform

The platform-native grounding path: a retriever wraps an Einstein Search operation and bridges a search index to your Prompt Templates and Flow, so an Agentforce agent answers over Data 360 instead of guessing. How it is assembled — Data 360's auto-created retriever per index versus a custom one in Einstein Studio, vector and hybrid search index types, no-code retrievers for admins versus custom for control, ensemble retrievers across sources — and the part that earns the platform its place: retrieval runs inside the Salesforce security model, honoring the running user's permissions by construction. The complementary line to an external RAG pipeline (principle 7), and the clean Data 360 model that has to come first.

Reference·Last updated 2026-06-03·Drafted by Lira · Edited by German Medina

Reach for Agentforce retrievers when the data you need to ground on already lives in Data 360 and the work runs inside the Salesforce security model. This is the platform-native build of the RAG pipeline what is grounding walks — ingest, chunk, embed, store, retrieve, augment, generate — except the platform runs the stages and you wire up the last one. The reason to pick it is not loyalty to a platform but fit: when the facts sit in the unified profile and the answer has to honor the user's permissions, Agentforce retrievers ground the prompt inside the security model you already operate, rather than asking you to hand-build retrieval and an access filter from scratch.

This page is how that grounding is assembled, part by part, and — just as important — what you own versus what the platform owns. You build and refine the retriever and choose the search index it draws from; the platform runs the embedding, the storage, the search, and the permission check. It is one composable instrument, not the whole kit: a real system often grounds an Agentforce agent on Data 360 and grounds an external agent on its own vector store off-platform, and they hand off. The vocabulary here — chunk, embedding, vector store, hybrid search, top-k — is the vocabulary from what is grounding; this page assumes it and shows where each piece lands on the platform.

The retriever: the bridge from a search index to the prompt

A retriever is a wrapper for an Einstein Search operation, created and refined in Einstein Studio. Its job is to be the bridge between a search index and the places a prompt gets built — your Prompt Templates and Flow. When an Agentforce agent grounds an answer, a retriever is what reaches into the index, pulls the chunks that match, and hands them to the prompt. It is the platform's name for the retrieve stage of the pipeline, packaged so you configure it rather than code it.

You get there two ways. Data 360 auto-creates a retriever for each search index, so the moment an index exists there is a working retriever over it — the fast path to grounding on a source. Or you build a custom retriever in Einstein Studio when you need more control over how retrieval behaves: the filters it applies, how results are ranked, the level of detail it returns. The auto-created retriever is the sensible default; the custom one is the lever you pull when the default's ranking or scope is not what the grounding needs.

One structural fact shapes every design here: one retriever fetches from one search index, and one search index indexes one DMO. A retriever is therefore scoped to a single source. When an answer has to ground on more than one — a profile DMO and a knowledge DMO, say — you compose an ensemble retriever that draws from several retrievers at once, rather than stretching one retriever past the single index it is built for.

Search index types: vector and hybrid

A retriever is only as good as the index under it, and Data 360 supports two search index types: vector search and hybrid search. Vector search is semantic retrieval — the embedding-based matching from what is grounding, where the query and the chunks are embedded and the nearest vectors come back. It catches meaning and paraphrase, and it is the right index when the corpus is prose and the queries are phrased in natural language.

Hybrid search combines keyword and vector retrieval and fuses the two result sets with a fusion ranker. This is the same hybrid-search idea your retrieval quality sibling lays out as a lever you would otherwise build — semantic for meaning, keyword for the exact strings that semantic search quietly drops (codes, IDs, names, rare terms) — here provided as a managed index type you select rather than a two-path merge you wire and tune yourself. When the corpus has exact terms that must match literally, hybrid is usually the index to choose, for the same reason it is usually the right default off-platform.

No-code retrievers and custom retrievers

The two ways to build a retriever map to two audiences. No-code retrievers let an admin bring unstructured data — PDFs, knowledge articles, call transcripts — into Prompt Templates and Flow for Agentforce to ground on, configured through filters and without writing vector query code. This is the path that puts grounding in reach of the people who own the content, not only the people who write queries: point the retriever at the unstructured source, set the filters, and the agent can answer over it.

Custom retrievers, built in Einstein Studio, are the same bridge with more control — finer filters, ranking, and level of detail, for the cases where the no-code defaults do not surface what the grounding needs. The line between them is the familiar one: the no-code path is the narrowest thing that does the job for most content, and the custom path is where you go when retrieval quality on a specific source needs a hand on the dials. Reach for the no-code retriever first and the custom one when the eval set says the default is missing chunks it should be finding.

Grounding inside the security model

Here is the part that earns the platform its place. Grounding through an Agentforce retriever runs inside the Salesforce security model — retrieval honors the running user's permissions by construction. A chunk the requesting user could not open through the front door is a chunk the retriever will not return to them, because the retrieval happens as that user, under their sharing rules, not as an unbounded reader of the whole index.

This is the platform's answer to the permission-leakage failure the grounding side has to solve everywhere — gotcha 8 in grounding gotchas, and principle 5: every retrieval path is a blast radius, and a flattened index that ignores who is asking turns semantic search into a confused deputy reading restricted material aloud. An external pipeline has to build that permission filter itself — tag every chunk with its access metadata at ingestion and filter on the requesting user at query time, before ranking — and getting it wrong is a data-exposure incident wearing the face of a helpful answer. On the Agentforce side, the filter is not something you remember to add; it is where retrieval runs.

The composition point: Agentforce retrievers here, an external pipeline there

Agentforce retrievers are one instrument, and the honest framing is composition, not choice (principle 7). The platform-native path is the right one when the data lives in Data 360 and the work runs in the Salesforce security model — the grounding, the embedding, the storage, and the permission filter are all handled where the data already sits. An external RAG pipeline is the right one when the corpus is off-platform, the data does not belong in Data 360, or the retrieval needs a control flow the managed index types do not give you — see external RAG for that side. A real system frequently grounds on both: an Agentforce retriever over the unified profile for the governed in-platform facts, an external pipeline over a document store for the rest, composed behind one agent.

A clean Data 360 model is the precondition on the platform side, exactly as a clean corpus is off it. A retriever grounds on a DMO, and a fragmented, stale, or wrongly-resolved model is confidently wrong no matter how good the retrieval over it — principle 2 lands here as much as anywhere. Run the Data 360 agent-readiness check before the agent grounds on marketing or service data, not after the first wrong answer ships. The retriever is the bridge; what it bridges to has to be worth grounding on.

The throughline

An Agentforce retriever is a wrapper for an Einstein Search operation that bridges a search index to your Prompt Templates and Flow: auto-created per index or built custom in Einstein Studio, drawing from a vector or hybrid search index, configured no-code by an admin or with finer control in code, and composed into an ensemble retriever when the answer spans more than one DMO. You own the retriever and the index quality; the platform owns the embedding, the storage, the search, and — the part that matters most — the permission filter, because retrieval runs inside the Salesforce security model by construction. That division is the whole appeal, and its whole limit: when the data lives in Data 360 and the work is governed, it is the most direct path to grounded, permission-aware answers; when the corpus is off-platform, that is the signal to compose an external pipeline and hand off. The skill is knowing where the data lives, not defending the instrument. (See grounding gotchas for the failure modes a platform-native build still inherits, and the grounding Style Guide for the bar a grounded system clears before it ships.)

Related

Reference: