Every Sales Cloud project I've run eventually arrives at the same uncomfortable conversation. The VP of Sales pulls up a pipeline review, points at a six-figure opportunity, and asks the rep when they last spoke to the customer. The rep has a confident answer. The CRM has nothing. There are no tasks, no logged calls, no emails, just a stage that quietly slid from "Proposal" to "Negotiation" with no evidence behind it. Multiply that across a team and you get the real disease: a forecast built on storytelling instead of activity.
I saw this in its purest form at a B2B telecom solutions provider with roughly eighty account executives. Before we touched anything, we measured how much of their actual work was making it into Salesforce. The number was about thirty percent. Reps were meeting clients, sending quotes from their corporate Gmail, having follow-up calls, and logging maybe one interaction in three. Their manager genuinely could not tell which rep was working which account, so coaching was guesswork and the forecast was fiction.
Activity capture is the cure, but it's also where I see the most expensive mistakes get made. The mechanics look simple. The decisions underneath them about where data lives, who can see it, and how long it survives are not. This is a walk through how I actually set this up, and where the landmines are.
Tasks and events are the foundation, and they behave more cleverly than they look
Underneath everything, Salesforce activity is just two objects. A task is something to do, with a subject, a due date, and a status. An event is something on the calendar, with a start and end time and attendees. Both link to the rest of the org through two fields that are worth understanding deeply because most "my activity isn't showing up" tickets trace back to them. The WhoId points at a person, either a lead or a contact. The WhatId points at the context, usually an account or an opportunity.
That WhatId is where reps trip. At the telecom client, a rep would open an account, click New Task, and Salesforce would helpfully default the WhatId to the account. The task was real and logged, but it never appeared on the opportunity, so the deal still looked dead. The fix is not training, it's configuration: build a New Task quick action directly on the opportunity layout that pre-fills the WhatId with the opportunity Id. Make the right thing the default thing.
A second decision that pays off is Shared Activities, which Salesforce calls "Allow Users to Relate Multiple Contacts to Tasks and Events." A standard activity links to one contact, but B2B deals don't work that way. When that telecom rep ran a pricing negotiation with four people from the buyer's side, we wanted that single meeting to surface on all four contact timelines, not just one. Shared Activities does exactly that, with one hard limit you must design around: fifty contacts per activity. I cap the quick action at fifty so a rep adding a sixty-person kickoff doesn't get a save error they can't explain.
I also enforce subject naming with a validation rule, something like requiring the subject to start with a bracketed phase, [Discovery] Send NDA. It feels bureaucratic until you build the first report grouped by activity type and discover the data is clean enough to actually trust.
Email logging is a menu, not a default
The moment you decide to capture email, you've picked one of four mechanisms, and they trade convenience against control in very different ways. Reps can send email directly from the Salesforce UI, which logs perfectly but forces them to live inside Salesforce. They can BCC a generated Salesforce address, which works from any client including mobile but depends on the rep remembering. They can use a Salesforce Inbox plugin in Outlook or Gmail and click "Log to Salesforce" per message, which keeps the data native and gives the rep full control at the cost of effort. Or they can turn on Einstein Activity Capture and let it sync automatically.
The choice should follow the client's actual tolerance for friction versus their need for control. The telecom client, engagement-heavy and competing on speed, wanted zero manual effort, so EAC was the obvious fit. A wealth-management client I worked with later, where every email to a private-banking customer is a potential legal document, deliberately chose the manual Inbox plugin so advisors consciously decided what entered the CRM. Same product, opposite decision, both correct for their context.
The one thing you must not do is enable two mechanisms at once. The most common duplicate-activity ticket I get is a rep who has both EAC and the Inbox plugin turned on, logging every email twice. Pick one, document the policy, and disable the rest.
Einstein Activity Capture works beautifully and stores data in a place that breaks half your assumptions
When we turned on EAC for the telecom team, the result was dramatic. Within a month, logged activity on opportunities went from thirty percent to ninety-two. Each rep connects their own mailbox once via OAuth (there's no admin-connects-for-everyone shortcut), and from then on EAC quietly matches inbound and outbound email against lead, contact, and opportunity-contact-role email addresses and attaches it to the right records. Calendar events sync the same way. Reps stop thinking about logging and the timeline just fills in.
Here is the part every consultant needs tattooed somewhere visible. EAC does not store email in the Salesforce database. The body and metadata live on an AWS bucket that Salesforce operates, for a maximum of twenty-four months, and the Lightning timeline renders by calling out to that bucket in real time. The captured records are Activity Metrics, not standard tasks.
The consequences ripple outward fast. You cannot query EAC email with SOQL, export it with Data Loader, or see it in a standard Tasks report, so any reporting has to lean on the Activity Metrics objects instead. Record-triggered flows and Process Builder that fire on task insert never run, because no task was inserted. If the client has automation that updates an opportunity's Last Activity Date off tasks, that automation silently stops working for the channel that now carries most of the activity. When this matters, I either keep tasks running in parallel or rebuild the automation against Activity Metric Summary. Telling a client this after go-live is a bad day; telling them in discovery is just good consulting.
Compliance and sharing are where EAC quietly fails the clients who need it most
The wealth-management engagement is the clearest illustration of where EAC hits a wall. Compliance handed us four requirements: keep customer email for seven years per regulation, let team leaders review their advisors' email, give compliance an audit trail of who viewed or changed what, and make any conversation retrievable on demand. Out of the box, EAC satisfied none of them.
Retention was the dealbreaker. EAC keeps email twenty-four months, then rotates it out of existence. There is a paid Activity 360 add-on, and clients routinely assume it means permanent storage, but it extends activity metrics to roughly twenty-five months while email bodies still expire. Salesforce is not an email archive, and you have to say that plainly. The design we landed on used EAC for daily convenience with group-based sharing, and ran journaling at the Exchange mail server in parallel to push a copy of every email into a dedicated archive system held for seven years, surfaced back in Salesforce through a deep-link on each customer account. EAC for the reps, the archive for the regulator.
The other trap is sharing, and it bites even non-regulated clients. The EAC sharing setting is not the standard sharing model. It is its own setting with exactly three options: Share with Everyone, Share with Groups, or Private, and it defaults to Private. Default Private means managers see nothing and can't coach. Share with Everyone, at a client with internal competition between B2B teams, means a rep's frank email about a customer's price complaint is readable by a rival rep on another account. Neither default is what most clients want. Worse, changing the setting later only governs new email; everything already captured stays on the old setting, so you get an inconsistent mess. Present a sharing matrix in discovery, get the business owner to decide who should see whose email, and set it before a single mailbox connects.
A few smaller things will still surprise the client. EAC syncs every fifteen to thirty minutes, not in real time, so reps need to know a just-sent email won't appear instantly. Internal one-on-ones between a rep and their manager get captured and can look like customer meetings unless reps tag them as internal. And because EAC is two-way, a rep who deletes an email from Gmail deletes it from Salesforce too, which means a determined rep can erase evidence unless you put a Vault hold on the mailbox at the mail server, outside Salesforce entirely.
The principle I keep coming back to is that activity capture is never really a feature decision, it's a data-residency decision wearing a feature's clothes. The instant you choose where the activity lives, you've decided what you can report on, what you can automate, who can see it, and how long it survives. Make that choice on purpose in discovery, and the rest is configuration. Discover it at go-live, and it's rework.
Implementing or optimizing Sales Cloud? Our Salesforce team runs discovery, designs the sales process, and configures Sales Cloud on production engagements. Get in touch ->
See our full platform services for the stack we cover.
