Einstein Activity Capture Reporting Changes: An Admin Checklist

Einstein Activity Capture reporting depends on your org’s configuration. Before rebuilding a missing-email report, establish whether your org uses legacy capture or Sync Email as Salesforce Activity. A timeline entry alone does not prove that the interaction is available to the report you are using.

Salesforce has announced that Activity 360 Reports, Activities Dashboard, Activity Metrics, and Recommended Connections retire in Spring ’27, which its notice identifies as February 2027. Review Salesforce’s retirement notice and confirm your org’s release schedule with your administrator. This checklist helps RevOps and Salesforce admins preserve useful reporting through that transition.

Reviewed October 15, 2026. The worksheet and test plan below are Revenue.io’s recommended planning approach, not Salesforce migration instructions. Confirm current migration availability and your org’s requirements with Salesforce.

First identify which email-capture architecture you use

Salesforce introduced Sync Email as Salesforce Activity in Summer ’25. With this setting, captured email is stored as Task and EmailMessage records and can be used by standard reporting and platform tools. Older configurations can behave differently. Salesforce’s architecture and retirement guidance explains the distinction.

Ask the administrator to record the current setting, date of EAC adoption, enabled legacy reporting features, and the objects behind each important report. Verify the configuration in Setup; an org’s age or the appearance of its activity timeline is not enough evidence.

• Already using the newer architecture? Focus on report definitions, filters, relationships, and access. Do not assume an old limitation still applies.
• Still using legacy features? Plan the architecture transition and the replacement of reports as separate workstreams.
• Unsure? Trace one approved test email from mailbox to Salesforce record to report before changing settings.

If the immediate problem is call logging rather than email reporting, use the separate guide to automatically logging calls and activities in Salesforce. Keep those channel-specific investigations separate.

Inventory dependencies before replacing a dashboard

The retirement notice says reports built on the legacy Unified objects stop returning data, Activity Metrics fields stop populating, and the old dashboard’s historical data is not retained. Treat downstream dependencies as part of the project, including reports that someone exports into a spreadsheet or presents at a weekly meeting.

Use this worksheet for each business-critical output. A named owner should approve its replacement before the legacy version is retired.

Start with decisions that depend on the data: an account coverage review, an unanswered customer email, or a manager’s coaching queue. A dashboard that looks similar but measures something different is not a completed migration.

Rebuild the metric definition before rebuilding the chart

Write a plain-language specification for every number. For example: “Unique outbound customer emails sent by the account team during the last complete calendar week, excluding internal-only messages.” That specification still needs decisions about ownership, duplicates, recipients, and eligible records.

1. Choose the unit: messages, activities, recipients, accounts reached, or conversations. Do not mix these in one total.
2. Define the time: sent date, activity date, or record creation date; calendar week or rolling window; agreed reporting timezone.
3. Define attribution: sender, activity owner, account owner, or opportunity owner. Record what happens after reassignment.
4. Define exclusions: internal messages, test mailboxes, automated messages, or records outside the intended team.
5. Define relationships: decide how unmatched emails and contacts associated with multiple opportunities should be handled.
6. Define the exception: state whether incomplete records are excluded, flagged, or routed for review.

Choose a report grain before combining records. If the reporting design joins related email and activity records, prove that one interaction is not counted twice. Do not treat agreement with an old aggregate as proof of correctness; both reports could share an error.

Confirm historical coverage before changing the setting

Salesforce’s architecture guidance describes migration availability as evolving and directs customers to Support for certain transitions. It also discusses including up to six months of past inbox email. That is not a promise that every historical dashboard or every old interaction will be reproduced in your org.

Before making a production change, obtain a written answer for your configuration: which records are included, the available date range, what is excluded, how duplicates are handled, and which legacy views become unavailable. Ask how you should preserve any required historical baseline using supported methods.

Create a reconciliation sheet with the report name, date range, filters, count, extraction date, and owner. Preserve only data your organization is permitted to retain, in an approved location. If detailed history cannot be carried forward, document the break in the trend line rather than quietly comparing incompatible periods.

Run a small, controlled reporting acceptance test

Use approved test records in a suitable environment. Confirm with your administrator which migration and capture behavior can actually be tested there; do not assume a sandbox reproduces production mailbox behavior.

Build a test sheet containing: scenario, expected record, expected report inclusion, actual result, evidence link, issue owner, and resolution. Include these cases:

• An outbound email to a known contact on the intended account.
• An inbound reply, with an explicit decision about whether the metric includes it.
• A message with several recipients, to test the counting unit.
• A contact with multiple possible account or opportunity relationships.
• An unmatched address, to inspect the exception workflow.
• A previously captured email, to test the agreed historical window.
• An internal-only message, to test exclusions.
• The same report opened by a rep, manager, and administrator.

Illustrative reconciliation: your reference set contains 20 eligible messages, but the report returns 22 rows. Two messages each have an additional related recipient row. Check the report’s grain and relationships before declaring that capture created duplicates. Conversely, 18 rows might reflect exclusions, access, timing, or association issues. Investigate the two missing examples individually.

Agree on pass conditions before testing: every critical example accounted for, intentional exclusions explained, correct role access, and unresolved issues assigned. Avoid an arbitrary “close enough” percentage for a report used to evaluate employees or make customer decisions.

Roll out with an owner and a comparison window

Separate technical readiness from business readiness. The administrator owns configuration and dependencies; RevOps owns metric definitions; managers approve decision usefulness; the appropriate governance owner reviews access and retention requirements.

Where your configuration permits it, compare the new output with a preserved baseline over an agreed window. Record explained differences, update subscriptions and bookmarks, and tell users when the metric definition changed. Do not promise that turning a setting back will restore a retired feature or historical view. Ask Salesforce about recovery options before the change.

The closeout record should identify the replacement for each critical output, its owner, the evidence used to accept it, remaining limitations, and the next review date. That record is more useful than a screenshot saying that the new dashboard loads.

When should you evaluate a broader activity-capture workflow?

A reporting migration does not automatically require a new vendor. First establish whether the current Salesforce configuration meets your needs. Consider a broader evaluation when the unresolved requirement involves calling, supported interaction capture, record associations, or rep follow-through.

Review Revenue.io’s Salesforce activity capture workflow against those requirements. Bring a sample report, a supported interaction, and an ambiguous record match to a product demonstration. Ask which modules and permissions are required, who resolves exceptions, and how the resulting records support your reporting design. Use pricing and package information to scope that discussion.

If replacement is the actual buying question, the existing Salesforce Einstein and Sales Engagement alternatives guide compares different workflow options. This checklist addresses reporting continuity.

Frequently asked questions

Can Einstein Activity Capture emails appear in standard Salesforce reports?

Yes, with the applicable Sync Email as Salesforce Activity architecture. Verify the setting, underlying records, report type, and access in your org. Avoid relying on blanket statements that all EAC email is unreportable.

Does seeing an email in the activity timeline prove it is reportable?

No. Check the capture architecture and the record available to the report. Then inspect filters, relationships, and permissions using a known example.

Is this the same as the Salesforce Open CTI retirement?

No. EAC reporting and Open CTI are separate changes. Keep their dependencies and project plans separate; the existing Open CTI migration guide covers the calling integration topic.