Case Study 08 · CModel Data, Inc · Systems Diagnosis

Diagnosing a Dead-End Integration: From "Which Reps Are Tracked?" to a Root-Cause Fix

Systems Diagnosis · Salesforce · Einstein Activity Capture · Root-Cause Analysis

Salesforce Einstein Activity Capture Microsoft Exchange Root-Cause Analysis
2
Root causes diagnosed — license/config, then dead auth method
11
Users — first org-wide working email/calendar sync
Zero
Rep behavior change required — fix was infrastructure, not adoption

The Ask

A months-old question nobody had actually answered: are reps' emails being captured in Salesforce?

Leadership wanted a straight answer to a question that had been sitting unresolved for months — were reps' emails being consistently captured in Salesforce? It read as a simple reporting request. It wasn't.

The Wrong Turn

The first pass measured the wrong tool entirely.

The initial approach was building an activity report — straightforward on the surface. But the report was measuring Outreach, a third-party sales sequencing tool that only logs emails sent through its own sequences. That's not what leadership meant. They meant native email capture — every email a rep sent, sequenced or not.

The distinction only surfaced after leadership pushed back and drew the line between the two themselves. Without that correction, the report would have shipped a confident answer to the wrong question.

Root Cause One

Einstein Activity Capture had 7 licenses, 0 configuration, and zero sync history — ever.

The real target was Einstein Activity Capture (EAC), Salesforce's native mailbox sync. It had 7 "licensed" users but nothing configured, and no sync history had ever existed. Tracing those 7 licenses led somewhere unexpected: every one belonged to an employee who'd left the company years earlier.

The current sales team had never been licensed for the feature at all. This wasn't a case of reps ignoring a tool they'd been given. The feature had never been turned on for anyone currently employed.

The Fix, Round One

Reassigned the licenses, scoped the sync deliberately, and turned it on for the real team.

The correction had three parts: fix the license and permission assignments, add the current team to the existing — empty — configuration, and scope the sync deliberately to emails and events only, deliberately excluding contacts to avoid an unrequested side effect on the CRM's contact data.

"Not an adoption failure — the feature had never been turned on for anyone currently employed. That distinction changes what you fix, and how you explain a months-old gap to leadership."

Root Cause Two — The Twist

A day later, it broke again. This time the whole auth method was already dead.

Everything broke again the next day. Tracing it back led to the Exchange connection itself — it was authenticating as a departed employee's login. Underneath that was a bigger problem: Microsoft had fully retired the underlying permission model, Application Impersonation, that the entire legacy integration method depended on.

This wasn't fixable with a permission grant or a new login. The auth method itself no longer existed on Microsoft's side.

The Real Fix

Migrated to the current supported auth model and rebuilt the configuration from there.

The fix meant migrating to the currently supported method — OAuth / Application-Level Authentication — which required coordinating with an external IT admin to complete the Microsoft-side consent step. With that in place, the EAC configuration was rebuilt on infrastructure that would actually keep working.

The Result

Live, working sync across all 11 users — the first time this org ever had it.

Confirmed live, working sync across all 11 current users — the first time this organization ever had functioning email and calendar capture. A leadership request that had sat unresolved for months closed with a clear paper trail distinguishing what actually happened: not "reps never adopted it," but "it was never built for anyone still here."


What Was Built