Einstein Activity Capture: the email store that hides your activity from reports and agents

You ask the service agent a fair question. When did we last email this account, and what did we say? The agent has the account, the open cases, every contact. It tells you it can’t find a single email.

So you open the account’s activity report to prove it wrong. That’s empty too. The emails are right there in the timeline on the record page. They just aren’t anywhere a query can reach.

The cause isn’t a permissions bug. It’s where Einstein Activity Capture keeps the email.

The emails EAC syncs don’t live in your Salesforce database. They sit in a separate store Salesforce runs, and the record page renders them by calling out to it. Nothing that runs a query sees them: not a report, not a list view, not SOQL, not a Flow, not a standard export. Data 360 can’t ingest them, and an agent can’t ground on them.

So the first move isn’t a better retriever. It’s turning that email into native Salesforce records with the setting called Sync Email as Salesforce Activity, and doing it before you promise anyone an agent that knows the relationship.

Where your captured email goes

Einstein Activity Capture connects a rep’s Microsoft or Google mailbox and calendar to Salesforce and captures the messages and meetings automatically. The surprise is the storage.

Captured email is written to what Salesforce calls the Activity Platform, an external store it runs on its own cloud infrastructure. It does not go to the EmailMessage and Task objects in your org. The timeline you see on a record is a live view of that store, fetched when the page loads.

It looks like your data is in Salesforce. Most of it is next to Salesforce.

Calendar events and contacts are generally handled as standard records. Email is the type that has stayed external, and email is usually the activity a sales or service team most wants to report on and reason over.

There’s a logic to it. Keeping years of full email bodies out of your org avoids a storage bill and some retention headaches. But the captured email is then only as reachable as the one screen that knows how to call the store.

The five things that can’t read it

The consequence is concrete, and worth spelling out, because “it’s external” stays abstract until it breaks something you needed:

Reports and dashboards have nothing to report on. There’s no record.
List views and the object model skip it. It isn’t a row in Task or EmailMessage.
SOQL and Apex return nothing, and no trigger fires, because nothing was inserted in your org.
Record-triggered Flow has no DML event to start on. “When a churning account emails us, alert the CSM” has nothing to hang on.
Standard exports and backups skip what was never in the database. Leave EAC and the history can leave with it.

Now add the two systems this blog spends most of its time on.

Data 360 ingests your org through connectors that read standard and custom objects, the rows in your database. It doesn’t reach into EAC’s external store. And an agent grounds on what a retriever can fetch, which in a Salesforce build means Data 360 or the objects in your org.

Chain those facts and you get the thing that started this post. An agent can’t ground on captured email, because the email was never anywhere the grounding layer looks. It’s the same dependency I walk through in does Agentforce need Data Cloud, and activity data is where it bites first, because everyone assumes the emails are already in Salesforce.

The record page shows you the email. That is not the same as your platform having the email. One is a window into another system. The other is a row you can query, report on, automate, and ground an agent on.

Sync Email as Salesforce Activity is the switch that matters

Salesforce closed most of this gap in the Summer ‘25 release, with a setting called Sync Email as Salesforce Activity. Turn it on and EAC stops treating email as external-only. It writes the email as native records instead: a Task and an EmailMessage, associated to the matching Contact, Lead, Account, and Opportunity.

Everything in the list above reverses the moment it does. The activity becomes reportable, queryable, visible to Flow, exportable, and, the reason it’s on this blog, ingestible by Data 360 and groundable by an agent. The query you couldn’t run now runs:

-- After Sync Email as Salesforce Activity is on, synced email is a native
-- Task (TaskSubtype = 'Email') you can query, report on, and ground on.
SELECT Subject, ActivityDate, WhoId, WhatId
FROM Task
WHERE TaskSubtype = 'Email'
  AND WhatId IN (SELECT Id FROM Opportunity WHERE StageName = 'Negotiation/Review')
ORDER BY ActivityDate DESC

There’s a choice to make when you enable it. Full capture writes the subject and body into the record. Header-only capture writes the participants and timestamps but leaves the subject and body out of Salesforce.

Header-only is the privacy-conservative option, and a real one. If you want activity signal, who talked to whom and when, rather than message content, it gives you the reportable metadata without landing every email body in your database. If you want an agent to answer “what did we agree in that thread,” you need full capture, and you need to have thought about what that means.

The catches, because there are four

Sync Email as Salesforce Activity is the right switch. It isn’t a silent one. Four things decide whether it helps or misleads you.

It matches on the email address. An email attaches to a Contact or Lead by matching the address on the message to a record in your org. A missing contact, a personal address, a shared inbox, or a stale record leaves the email unlinked or on the wrong record. Thin contact data makes a thin sync, which is the unglamorous reason data quality is the prerequisite for anything you ground an agent on.

It doesn’t capture everything. Attachments, opens, and clicks don’t come across in the activity record. If your use case depends on whether someone opened the email, this isn’t your tool.

It’s forward-looking. Enabling it starts writing new email as native records. It does not convert the years already sitting in the external store. There’s a limited backfill window when you switch it on, reported to be a few months, and you should confirm the current figure for your edition before promising anyone historical coverage. For an org that ran EAC for three years expecting the data to be “in Salesforce,” that’s an unwelcome discovery.

Full bodies are full of PII. The moment email bodies become native records, they fall under your sharing model, your retention, and your agent’s retrieval. An email body is one of the richest sources of unmanaged sensitive data in an org: a card number a customer pasted, health details, a home address. Before an agent retrieves over synced email, run Data Detect across those fields so you know what’s in there, and scope the retriever to what the running user may read. Making email queryable is what makes it leakable.

The path from a synced email to a grounded answer

Once the email is native, the rest is the normal grounding chain, and it’s worth drawing so you can see there’s no shortcut that skips the native-records step:

Enable Sync Email as Salesforce Activity, full capture if the agent needs content, so email lands as Task and EmailMessage records.
Ingest those objects into Data 360 through the Salesforce CRM connector and its starter bundles, which map standard objects into the data model. Activity comes across the same way accounts and contacts do.
Point a retriever at the mapped activity so the agent can fetch it. The retriever and search-index choices decide what the agent reads and how relevant it is.
Ground the agent on that Data 360 data, the same way you’d ground it on any knowledge or record data.

Skip step one and every later step has nothing to work with. That’s the point worth carrying out of here. An agent that “can’t find the email” almost never has a retriever problem. It has a records problem upstream, and the records problem is EAC’s external store.

Two deadlines that are already on top of you

Two EAC changes have real dates, and because it’s late September 2026, one has already passed. Check both against your org now.

The first is the Exchange Web Services cutover. Microsoft is retiring EWS, and Salesforce set a deadline to move EAC’s Microsoft 365 and Exchange connections from EWS to Microsoft Graph. That deadline fell in early August 2026, and Microsoft’s own EWS retirement in Exchange Online is phased from October 2026.

In plain terms, if an EAC connection in your org still authenticates with EWS, it may have already stopped syncing. Open the Einstein Activity Capture settings in Setup, check the connection’s authentication method, and if it reads EWS, move it to Microsoft Graph and re-consent in Azure. Rule this out as a live incident, not a future project.

The second is the old activity reporting layer. Salesforce has been retiring the legacy Activity 360 reporting features, Activity Metrics, the analytics dashboard, and recommended connections. They’ve been off for newly created orgs for a while, and the full retirement date has already slipped once, so read the current release note for your release rather than trusting any single blog’s month.

The direction is clear even where the date isn’t. Salesforce wants activity reporting done with standard reports over native records, which is the same place Sync Email as Salesforce Activity takes you. Building on the old dashboards now is building on something with a retirement notice attached.

What to do this week

If leadership wants an agent that understands the customer relationship, the activity plumbing is the unglamorous first step, and it’s mostly configuration, not code.

Confirm which mailboxes are still on EWS and fix them. Decide full versus header-only capture as a governance question, not a default. Turn on Sync Email as Salesforce Activity so new email lands as native records, and set expectations that the back catalogue in the external store mostly stays there. Run Data Detect over the newly native fields before anything reads them. Then ingest the activity objects into Data 360 and point a retriever at them.

Do that and the empty report fills in, the Flow you couldn’t trigger has an event, and the agent that shrugged at “when did we last email this account” answers it from a row it can read. The agent was never the problem. The email was in the wrong place.

Understanding the basics

Why can’t I report on Einstein Activity Capture emails?

Because EAC writes captured email to an external store Salesforce operates, not to the Task and EmailMessage objects in your database. Reports, list views, SOQL, and Flow only see records in your org, so email that lives only in the external store is invisible to them. The timeline on a record page is a live view of that store, which is why the email shows there but nowhere else.

What does Sync Email as Salesforce Activity do?

It changes EAC so synced email is written as native Salesforce records, a Task and an EmailMessage linked to the matching Contact, Lead, Account, and Opportunity, instead of living only in the external store. Once email is native it becomes reportable, queryable, automatable, ingestible by Data 360, and groundable by an agent. You choose full capture or header-only capture, which is a privacy decision as much as a functional one.

Can Agentforce or Data 360 use Einstein Activity Capture data?

Only after the activity is written as native records. Data 360 ingests standard and custom objects from your database; it doesn’t reach into EAC’s external store, and an agent grounds on what Data 360 can supply. The working path is: enable Sync Email as Salesforce Activity, ingest the resulting Task and EmailMessage records into Data 360, then point a retriever at them and ground the agent.

Does turning on Sync Email as Salesforce Activity import my old emails?

Mostly no. The setting is forward-looking, writing new email as native records from the moment you enable it. There’s a limited backfill window, but it doesn’t convert the full history already sitting in the external store. Confirm the current backfill window for your edition before you commit to a historical-coverage number.

If you’re trying to get an agent to reason over your real customer activity and finding the data isn’t where you thought it was, talk to us. Getting the activity foundation native, governed, and ingestible, so an agent grounds on it instead of shrugging at it, is the kind of integration and Data 360 work we do.