Your Einstein Activity Capture Rollout Isn't Live Until Every User Ticks a Box

There's a particular kind of silence that follows an Einstein Activity Capture go-live.

The admin work is done. The org-level connection to Microsoft 365 or Google Workspace is authenticated. The sync configuration is saved, the sharing defaults are set, the users are assigned. Setup says everything is connected. And then a week later, someone opens an Opportunity, looks at the activity timeline, and finds nothing there.

Nobody misconfigured anything. The rollout just stopped one click short of the finish line — at the consent screen each end user has to accept before a single email is captured.

That last step is invisible from the admin console, it takes about thirty seconds, and in our experience it is the single most common reason an EAC deployment appears to have failed.

The thirty seconds in question

Here is the entire end-user journey, from a live org:

1. Open personal settings. Click the profile avatar at the top right of Salesforce, then Settings.

   

2. Find the connected account. In the settings menu, expand Connected Accounts and select Email and Calendar Accounts.

   

3. Read the consent modal. A dialog appears — Terms for Capturing and Sharing Emails — explaining what will be captured and how it will be shared. Tick I've read and understand these terms.

   

4. Save. Scroll to the bottom and hit Save.

   

That's it. Activity capture begins, and the timeline starts filling in.

The reason this stalls so reliably isn't difficulty. It's that nothing in a salesperson's daily workflow ever takes them into personal settings. They live in list views, records, and the Outlook or Gmail panel. Left to discover it themselves, a meaningful chunk of your user base simply never will — and they won't report it as a problem, because from where they're sitting, nothing is broken. The timeline was always empty.

What that consent screen is actually telling you

It's tempting to treat the modal as legal boilerplate to click past. Read it properly, though, and it's the clearest plain-language summary of your org's configuration that Salesforce will ever hand your users.

The version our users see says, in effect: your admin has already connected your email and calendar account, but capture won't begin without your authorisation. Your emails will be stored in Salesforce and added to the activity timeline of related records. That email data is also used to generate email insights and to improve the service. Whether your emails are shared depends on the default activity sharing settings your admin controls — and you can change your own setting later, including whether text from the subject and body is captured at all.

Then it states the two rules the org has actually been configured with:

• Emails between you and your coworkers aren't shared to Salesforce.

• For emails that are added, the sender, recipients, participants, date, and derived insights may be visible to everyone in the organisation.

Those two lines are not generic text. They're a readback of choices your admin made. Which means the consent screen is quietly doing something valuable: it's the moment your users find out how visible their correspondence is about to become.

Two practical consequences follow.

First, get the sharing defaults right before you send anyone to that screen. The alternative is a user reading "may be shared with all Salesforce users in your organization," deciding that sounds like more than they signed up for, and clicking Decline. A declined consent is far harder to recover than an un-clicked one, because now you're relitigating trust rather than sending a reminder.

Second, in this region especially, loop in whoever owns your data policy before go-live, not after. Capturing customer correspondence into a CRM and making participants and metadata visible org-wide is a reasonable thing to do — but it is a decision with PDPA implications, and it's much easier to have that conversation while sharing settings are still adjustable than in response to a complaint. We're consultants, not lawyers; the point is only that this belongs on the pre-launch checklist rather than in the post-mortem.

What actually makes adoption stick

The pattern that works is unglamorous:

• Communicate before you enable, not after. A short message explaining what's being captured, what isn't, and why, sent before the modal appears, prevents most declines. Users who meet the consent screen cold tend to read it defensively.

• Give them the screenshots. A four-slide guide with the exact click path — avatar, Settings, Connected Accounts, tick, Save — costs an hour to produce and removes every excuse. This post exists because we built exactly that deck for a client, and it worked better than any amount of explanation.

• Pilot, then expand. Ten users, validate that timelines populate, fix what surfaces, then roll out by profile rather than one user at a time.

• Verify, don't assume. Consent status is per-user. Check who has actually accepted rather than trusting that the announcement email landed.

• Set expectations about the timeline. After acceptance there's a preparation window before data appears. Users who expect instant results conclude it's broken and stop looking.

And a note on timing

If you're planning an EAC rollout in the second half of 2026, two things are worth pulling forward in your calendar.

Microsoft is retiring Exchange Web Services for Office 365 in October 2026, which is what finally ends Lightning Sync — Salesforce has been recommending migration to EAC for years, and the runway is now measured in weeks rather than releases. Orgs on Microsoft 365 have been moving to Microsoft Graph authentication automatically since Spring '26, but "automatic" still deserves a verification step in your plan.

The other item is where captured email lives. Historically EAC stored it outside the standard Salesforce database, which is why it appears on the timeline but not in reports, flows, or Apex. The Sync Email as Salesforce Activity option introduced in Summer '25 writes new captured emails as native records instead — the fix for the reporting gap that has frustrated RevOps teams for years. Two caveats worth knowing before you flip it: the migration is one-way, and historical backfill is capped, so older data stays where it is. If you intend to report on activity, decide this before you onboard users, not after you've accumulated a year of history in the wrong place.