Ground Agentforce in Your Own Documents: RAG with Data Cloud Retrievers

A language model knows nothing about your refund policy, your programme handbook, or last quarter's cases. Retrieval augmented generation fixes that by finding the relevant passages of your own content and putting them in the prompt before the model answers. On Salesforce this is Data 360 doing the retrieval and Agentforce or a prompt template doing the answering. This guide walks the whole path and then covers the levers that actually change answer quality, because the setup is the easy half.

What RAG is on Salesforce

The mechanism, in one paragraph. Your content is split into chunks. Each chunk is converted into a vector embedding, which is a numeric representation of meaning. At question time, the question is embedded the same way, and the system finds the chunks whose vectors sit closest to it. Those chunks go into the prompt as context. The model answers from them rather than from memory.

Three consequences follow, and they explain most RAG failures:

• The model can only answer from what retrieval returns. If the right chunk is not retrieved, the answer is wrong no matter how good the model is. RAG quality is a retrieval problem first.
• Chunk boundaries determine what a chunk means. A chunk that splits a procedure in half retrieves badly, because neither half is a complete thought.
• Stale content produces confident stale answers. Retrieval has no opinion about whether a document is current.

The Salesforce pieces, named properly, because the acronyms are unavoidable in the setup screens:

Data library or custom retriever

Decide this before you build anything, because it determines how much work you are signing up for.

An Agentforce Data Library is the fast route. Point it at Salesforce Knowledge, upload files, or use web search, and Salesforce creates the vector store, the search index, and the retriever for you with sensible defaults. You can have an agent answering from your documents inside a day.

Its limits are real: one data source per library, no combining sources, no real time access, and no zero copy, so external content has to be downloaded and uploaded as files.

Custom retrievers on Data 360 are the route when you need more. Multiple sources, harmonised and unified data, real time or zero copy content, and full control over chunking, filtering, and search behaviour.

The rest of this guide covers the custom route, since that is where the decisions are.

Step 1: Get the content into Data 360

What you index depends on where the content lives.

• Salesforce Knowledge. Index the Knowledge Article Version object. It is the natural grounding source for support agents, and the Description field usually carries the substance while Title gives useful context.
• Files in object storage. Connect Amazon S3 or similar, ingest as unstructured data, and Data 360 maps it to a UDMO.
• Website content. Ingest with the website connector, which is the cleanest way to keep public policy pages as a grounding source.
• CRM records with long text. Case Subject and Description, for example. Indexing resolved cases is an underrated grounding source, because it captures how problems were actually solved rather than how the handbook says they should be.
• Warehouse data. Use zero copy federation rather than copying it.

Before you index anything, do one unglamorous task: confirm the content is current and that somebody owns it. Indexing an abandoned document library is the single most common way to build a confidently wrong agent. If nobody can name the owner of a document set, it is not ready to ground an agent.

Step 2: Choose a chunking strategy

This is the decision with the largest effect on answer quality, and it is usually made by accepting a default.

Configure it under Advanced Setup when you create the search index. The levers:

• Chunking strategy. Section aware chunking respects the structure of the source, splitting on headings rather than at an arbitrary character count. For structured content such as handbooks, policies, and well-built web pages, this is materially better than fixed size chunking.
• Max tokens. The default is 512. You can go up to 1,200. Larger chunks carry more context and retrieve fewer, more complete passages. Smaller chunks are more precise but more likely to cut a thought in half.
• Overlap tokens. Overlap repeats a little text between adjacent chunks so a sentence spanning a boundary still appears whole somewhere. Use overlap when your content runs continuously with weak structure. Use zero overlap when pages are well structured, because it keeps the chunk set cleaner.
• Title prepending. Add the document or section title to each chunk. This is a small setting with a real effect: a chunk that says "Refund window" plus its parent title "Enterprise contracts" is far more retrievable than the chunk alone.
• Vectorization strategy, meaning the embedding model. This must support your chunk size. Salesforce Embedding V2 Small, also referred to as SFR-v2-small, supports a 1,200 token chunk size. If you choose 512 token chunks, use a model with a correspondingly smaller supported sequence length.

A sane starting point for structured documents: section aware chunking, 1,200 max tokens, zero overlap, title prepending on, Salesforce Embedding V2 Small. For continuous prose with poor headings, drop to 512 tokens and add overlap.

Step 3: Build the search index

In Data Cloud, create a new search index configuration and choose Advanced Setup so you get the parsing and chunking options rather than defaults.

Search type: vector or hybrid

Choose hybrid search unless you have a specific reason not to. Vector search alone finds semantic similarity, which is excellent for paraphrased questions and poor at exact terms. Hybrid search combines vector search with keyword search, then merges the two result sets with a fusion ranker.

This matters because your domain vocabulary is exactly what vector search handles worst. Product codes, policy numbers, medication names, grant identifiers, and internal acronyms are precise tokens where keyword matching wins. Any real enterprise content contains plenty of them.

Under the hood, hybrid search uses Reciprocal Rank Fusion, the industry standard approach, summing the reciprocal rank scores from the keyword (sparse) and vector (dense) result sets with a default rank constant of 60. An alpha parameter controls the sparse weight in the combination, so you can shift the balance toward keyword or semantic matching.

Ranking factors and filters

Two configuration choices made at index creation time that you cannot easily revisit later:

• Ranking factors such as recency and popularity feed into the fusion ranking model. Recency is valuable for content that supersedes itself, like policy documents and release notes. Turn it on where newer genuinely means more correct.
• Filter fields. Select up to 10 fields, from the indexed object or related objects, to use as pre-filters at query time. This is how you scope retrieval to a language, region, product line, or audience.

Think hard about the filter fields now. They are the mechanism for keeping internal content out of a customer facing agent's reach, and for keeping one brand's answers out of another brand's conversation. Adding them later means rebuilding the index.

Enriched chunks

Optionally enable enriched chunks. Data 360 then generates three chunks instead of one: the original text, a chunk of metadata text, and a chunk containing questions that the passage can answer. That last one is the useful part, because it matches how users actually phrase things. It costs more storage and processing, so treat it as a targeted improvement for a corpus that retrieves poorly, not a default.

Step 4: Create the retriever

Go to the AI Models tab in Data Cloud, formerly Einstein Studio, open the Retrieve tab, and create a new retriever.

1. Choose the retriever type. An individual retriever reads from exactly one search index, and a search index covers exactly one DMO. If your use case needs several sources, use an ensemble retriever, which combines them.
2. Select the source: Data Cloud, the data space, then the DMO and its search index configuration. Note that the data space is a security boundary, so choose deliberately in a multi-brand org.
3. Define filters. All Documents is the unrestricted default. Apply a filter here when the retriever should only ever see a subset, which is cleaner than hoping the prompt asks nicely.
4. Set the number of results. The default is 20.
5. Map the fields to return. This step is more important than it appears. You name each returned field and map it, choosing direct attributes from the indexed object, such as Subject or Description, or related attributes such as the chunk text itself. A typical set is a title field, a body or description field, the chunk text, and a URL for citation.

Always return something citable, a URL or a record identifier. An answer a user can verify gets trusted and adopted. An unsourced answer gets second-guessed, and the deflection benefit evaporates.

Step 5: Use it in a prompt template

In Prompt Builder, create a template and add the retriever as a grounding source. The retrieved chunks are merged into the prompt at run time.

What separates a good grounded prompt from a bad one:

• Instruct the model to answer only from the provided context, and to say plainly that it does not know when the context does not cover the question. This single instruction removes a large share of hallucinations.
• Ask for citations using the fields your retriever returns.
• Set the audience and tone explicitly. Content written for internal staff, restated verbatim to a customer, reads badly and sometimes leaks detail it should not.
• Test with the questions you are afraid of, not the ones you designed for. Edge cases, ambiguity, and questions the corpus genuinely cannot answer. A grounded prompt that refuses correctly is working.

Prompt Builder shows you the resolved prompt, including retrieved chunks, before you deploy. Use it. Reading what retrieval actually returned answers most "why did it say that" questions in seconds.

Step 6: Turn it into an agent action

A prompt template becomes an agent action, which the planner can select. Two things to get right:

• The action description is functional. The planner chooses actions by reading descriptions. "Answers questions about shipping, delivery times, and tracking using published policy documents" is selectable. "Knowledge action" is not.
• Put it in a narrowly scoped subagent. A subagent that owns one job routes reliably. One that owns everything does not.

Then run it through Agentforce Testing Center with a set of real utterances, and check retrieval quality separately from answer quality. They fail differently and they are fixed differently. The wider design context is in the Agentforce and Data Cloud reference architecture.

Tuning: what actually improves answers

In rough order of effect, based on doing this repeatedly:

1. Fix the content. Remove superseded documents. Nothing in the retrieval stack compensates for a corpus containing three contradictory refund policies.
2. Fix chunk boundaries. Move to section aware chunking. Verify that a chunk contains a complete idea by reading a sample. Actually read them.
3. Switch to hybrid search if you began with vector only and users search by identifiers or jargon.
4. Turn on title prepending. Cheap, and it consistently helps.
5. Adjust the number of results. Too few and the answer misses context. Too many and the signal is diluted with marginal chunks. Change it and measure rather than reasoning about it.
6. Add recency as a ranking factor where newer content is more correct.
7. Shift the alpha weight toward keyword matching if precise terms are being missed, or toward vector matching if paraphrased questions fail.
8. Try enriched chunks on a corpus that still retrieves badly after all of the above.

Notice that the first two items are content and structure, not configuration. That ordering holds in practice more often than teams expect.

Debugging bad answers

Separate the two failure modes before changing anything, because they have nothing in common.

Always inspect the resolved prompt first. Roughly half of reported RAG failures are prompt or content problems wearing a retrieval costume.

Governance and cost

Three things that are easier to decide now than to retrofit:

• Who owns the corpus. Name a person responsible for whether the indexed content is current. Without this, quality decays silently and the agent slowly becomes wrong.
• Audience separation. Internal and external content should not share an unfiltered index. Use filter fields or separate indexes. Get this wrong and a customer facing agent quotes an internal escalation procedure.
• Cost shape. Data 360 usage is consumption based, in credits. Indexing, storage, and retrieval all consume. Enriched chunks triple chunk volume. Reindexing a large corpus repeatedly during tuning is not free, so tune on a representative subset before you rebuild everything.

The last one is worth saying plainly, because teams often discover it after a month of enthusiastic experimentation: prove the configuration on a slice, then scale it.

Frequently asked questions