Data 360
Where your Agentforce conversation transcripts live, and how to get them out
The message your agent sent a customer may not be in Salesforce at all. Enhanced-channel and messaging transcripts live in a separate off-platform store you cannot reach with SOQL, agent reasoning traces expire in 72 hours, and the Trust Layer audit log only exists if you turned it on. This is the map of where conversation data goes, the three ways to get it out, and what deletion has to reach.
Someone in legal asks a reasonable question: pull every message our agent exchanged with this customer over the last six months. You write the SOQL, run it, and get almost nothing back. A MessagingSession row or two, with no message text in them.
The conversation happened. The customer has screenshots. But the words your agent said are not where you expected them to be, and depending on the channel, they may not be in your org’s core database at all.
The mental model is what trips teams up. We assume a conversation is a record like any other: stored in Salesforce, queryable with SOQL, reportable, covered by the org’s data policies. For a large and growing share of agent and messaging traffic, none of that is true.
Conversation data is split across three stores with three access methods and two retention behaviours, and the compliance implications surface only when someone needs the data and cannot get it, or when a right-to-be-forgotten request has to reach copies you forgot existed.
Not everything is in Core
Salesforce stores conversation data in one of two places depending on the channel: Salesforce Core storage, or a separate off-platform database running on AWS, built for the scale and latency of real-time messaging. The documentation is explicit that the channels you use determine where the data lands. The practical consequence is the part people miss.
For standard channels, conversation entries are on-platform. You can query and report on them the ordinary way.
For Enhanced Messaging channels and Messaging for In-App and Web, increasingly the default for new deployments, the message content is stored off-platform, and the message text is not available through SOQL or standard reporting.
You can query MessagingSession and MessagingEndUser for the session metadata and the conversation identifier. To retrieve the messages themselves you go through the Connect REST API. The ConversationEntry object exists in two forms, an on-platform SObject and an off-platform schema, and for enhanced channels the words live in the off-platform one.
Voice is its own shape again. Service Cloud Voice spreads call data across Task, VoiceCall and ConversationEntry, and voice conversation entries are retrievable through both SOQL and the Connect API.
There is an upside buried in this design. Conversation transcripts do not consume your org’s data storage allocation the way a comparable volume of custom-object records would, which is a relief for high-volume contact centres. The trade is discoverability. The data that does not count against your limits is also the data your report builder cannot see.
So the first thing to establish for your own org is simple and non-obvious: which of your channels write to Core and which write off-platform. That one fact drives every access, reporting and deletion decision downstream.
The three doors out of the off-platform store
Once you accept that the message text lives off-platform, the question becomes how to get it. Salesforce documents three methods, and each is built for a different job.
The Connect REST API is real-time, granular and narrow. The Conversation Entries resource returns the transcript for one specific conversation. Use it for a record-page component or a flow that needs this conversation now.
Its constraints define its lane: text only, no rich content, no bot messages, essentially one conversation per call, and rate-limited. Right for interactive retrieval. Wrong for six months of history.
The bulk export tool is complete but slow. For a full archival extract, it exports all message data across Voice, Enhanced Chat, enhanced Facebook Messenger and enhanced WhatsApp. The operational limits are the whole story. You can run it only once every seven days, and the exported files must be downloaded within 30 days before they expire.
Salesforce positions it as an archival and compliance mechanism rather than a syncing tool: after an initial bulk export you move to an API for incremental updates. This is the door your compliance team’s archival vendor ingests through, and the seven-day cadence is why you cannot lean on it for live reporting.
Syncing to Data 360 is the analytics and grounding path. For anything continuous, such as reporting, dashboards, agent grounding or conversation mining, you sync the off-platform data into Data 360 by creating data streams for conversation transcripts. You enable conversation-transcript access in Data 360 first, then stand up the streams.
The data lands as documented objects, a Conversation data lake object covering digital-engagement channels and a Conversation Entry Transcript Excerpt DMO, where it becomes queryable with SQL, reportable, and available to retrievers. Salesforce documents this as the recommended path for bulk use cases because it sidesteps the API’s one-conversation-at-a-time limit, and notes it comes at no additional cost for most customers.
The decision rule writes itself. One conversation, interactively: Connect API. A complete archive on a compliance schedule: bulk export. Reporting, mining or grounding at scale: Data 360. Most mature deployments use all three for different jobs, which is fine as long as you know which copy of the data each one reads.
The agent’s own reasoning is a separate, short-lived record
Everything above is about what the agent said. What the agent did, the reasoning, the topic classification, the actions it fired and the LLM calls behind them, is captured separately, and its retention behaviour is the one that catches teams during an incident.
Agentforce Session Tracing records agent interactions end to end: turn-by-turn exchanges, reasoning-engine executions, the actions taken, gateway inputs and outputs, errors, and the final response, unified under a session ID and stored in Data 360 where you can query it with SQL. There is also a Session Trace OpenTelemetry API that returns a full trace as OTel spans you can export to Splunk, Datadog, New Relic or any OTLP collector. Invaluable for wiring agent behaviour into the observability stack you already run.
Read its limits before you rely on it. It returns a single session per request, there is no bulk query, and the session must have started within the previous 72 hours. Built for incident investigation, not archival. If you want agent reasoning to survive beyond that window, you persist it yourself, into Data 360 or your observability platform, on the way past.
The Agentforce observability tooling surfaces per-session events for live inspection, but “I can see it in the builder today” is not the same as “it will be there when someone asks in Q3”.
The Trust Layer audit log exists only if you turned it on
Now for the compliance trap that does the most damage. The Einstein Trust Layer masks PII before a prompt leaves Salesforce, enforces a contractual zero-retention arrangement with the external model providers so your prompts and responses are not retained or used for training, and can log an audit trail of every interaction into Data Cloud through the Einstein Audit and Feedback data model, which ships with prebuilt dashboards. The trail covers the prompt, the response, the masked entities, toxicity scores, the grounding sources, the user, the timestamp, and any thumbs-up or thumbs-down feedback.
The word carrying the weight is can. Collection of that audit and feedback data must be explicitly enabled. You agree to store it in Data Cloud in the Trust Layer settings. Teams routinely assume it is on by default because “trust layer” sounds like something that is always recording. Nothing records unless you switch it on.
If you have not enabled it, and months later someone asks you to show what the agent was told, what it saw and what it answered on a specific date, the record does not exist. You cannot retroactively generate an audit trail for interactions that happened before you switched it on. For any regulated deployment, and certainly anything in scope of the EU AI Act’s logging expectations, enabling this on day one is the difference between having an answer and having an incident.
Retention and deletion: know where the copies are
Two retention realities matter, and I will state only what is documented, because this is exactly the area where guessing a number is worse than admitting you do not have one.
What is documented: bulk-export output is available for 30 days before it expires, session traces reach back 72 hours, and once conversation data is synced into Data 360, its lifecycle follows your Data 360 data-space retention policies, which you configure. What I would treat as not reliably documented is a single baseline retention period for the off-platform store before Salesforce deletes it. If a specific figure matters to your compliance posture, get it in writing from Salesforce for your channels and edition.
The safe operating assumption is that the durable, controllable copy is the one you deliberately land in Data 360 or an external archive. If long-term retention is a requirement, make that copy rather than assuming the platform keeps one for you.
Deletion is the mirror image, and it is where the split-storage model bites hardest. A right-to-be-forgotten request for a customer now has to reach conversation data in up to three places: Core, the off-platform AWS store, and any Data 360 copy you synced. Salesforce provides distinct mechanisms, voice-call data deletion and Data 360 data-deletion requests among them, and they are distinct on purpose. A deletion that clears one store while leaving another is a real GDPR exposure.
The right-to-be-forgotten work is only as complete as your inventory of where the data went. Map your channel-to-storage layout before you are handling a live erasure request under a clock. The same discipline that governs data archiving and the delete decision applies here, with the added twist that some of the copies are not in Salesforce at all.
Understanding the basics
Are Agentforce conversation transcripts stored in Salesforce?
Only for standard channels. Transcripts from Enhanced Messaging channels and Messaging for In-App and Web are stored in a separate off-platform database on AWS. You can query the session metadata with SOQL, but the message text itself is only available through the Connect REST API, a bulk export, or a Data 360 sync.
How do I export Agentforce conversation history?
Three ways. The Connect REST API returns one conversation’s text at a time. The bulk export tool exports all message data but runs at most once every seven days, with a 30-day window to download the files. For reporting, mining and agent grounding at scale, create Data 360 data streams for conversation transcripts, which land the data as queryable objects.
How long are Agentforce session traces kept?
The Session Trace OpenTelemetry API returns a single session per request and only for sessions that started within the previous 72 hours. If you need agent reasoning for longer, export traces to Data 360 or your observability platform as they are generated.
Is the Einstein Trust Layer audit trail on by default?
No. Audit and feedback data collection must be explicitly enabled in the Trust Layer settings, and it cannot be backfilled for interactions that happened before you switched it on. Enable it before launch for any deployment that may need to show what an agent was told and what it answered.
Treat the storage map as part of the build
Conversation data is the highest-value exhaust an agent produces. That exhaust is how you improve deflection, mine intent, ground the next version of the agent, and prove to a regulator what happened. It only becomes an asset once you know where it lives and have routed it somewhere durable and queryable.
Map the channels to their stores, pick the export door by the job, persist traces before the 72 hours run out, turn the audit trail on before launch, and make sure deletion reaches every copy. Do that as part of the agent build, not the first time legal comes asking.
If you need the storage map drawn for your channels before an audit, a retention review, or an erasure request lands, talk to us, or check the wider picture first with the org health scorecard.
