CRM Activity Sync Audit: Find Missing Sales History
A CRM activity sync audit should reconcile individual interactions against an agreed logging policy. Check the source event, destination activity, customer association, responsible user, and required content. Matching totals cannot establish that the right sales history arrived: one duplicate can conceal one missing reply.
This guide is for administrators investigating gaps after connecting email, calendar, calling, or another CRM. In our executed synthetic exercise, eight eligible events and eight destination rows produced equal totals, but six events had exceptions. The downloadable example shows how to find them. Teams choosing an integration for the first time should also use the broader CRM Gmail integration checklist.
Define the CRM activity sync audit population
Start with one integration, one direction, one activity type, and a fixed observation window. Write down the connected users, applicable exclusions, historical import boundary, and the point after which an event should have arrived. Save that configuration with the audit.
A mailbox contains interactions that may intentionally stay out of the CRM. An internal conversation, an excluded address, or an event outside the agreed history window belongs in an exclusion register with a reason. Counting every source event as a required CRM row creates false missing-activity alerts.
Separate these populations:
- Eligible and due: the policy requires the event, and its agreed arrival deadline has passed.
- Eligible and waiting: the event is still inside the allowed processing window.
- Excluded: the policy says the event should stay out or outside the selected import scope.
- Unresolved: available evidence does not establish eligibility or identity.
Review excluded items too. An exclusion working as intended should not appear as a logged interaction through another path. Keep unresolved cases visible rather than quietly removing them from the denominator.
Use CRM field ownership to decide who controls assignment and customer identity. The contact management requirements checklist helps define whether a person, account, or opportunity association is required for the workflow.
Choose the unit before comparing totals
A message, a conversation thread, a calendar series, a meeting occurrence, and a database row are different units. Two replies within one thread may represent two required interactions. One interaction may also create multiple related CRM objects.
Write a normalization rule for each activity type. For email, you might reconcile one logical message using a source-qualified message key and the connector's destination mapping. Preserve the thread key separately. If the connector exposes no dependable mapping, mark an ambiguous match for review instead of treating the subject line as a unique identifier.
Calendar updates need their own rules: distinguish a rescheduled occurrence from a new meeting, record cancellation state, and retain occurrence identity for recurring events. Do not combine calendar counts with email counts until both have a defined unit.
Verify current capture settings before diagnosing loss
We checked the following primary sources on October 23, 2026. These are documentation observations, not tests in HubSpot or Salesforce accounts. Confirm the actual account configuration and integration path before applying them.
HubSpot: distinguish the two activity paths
HubSpot's Salesforce activity sync documentation separates Timeline sync from Activity sync. Activity sync supports tasks, sales emails, calls, and meetings, with controls for direction, deletion, mappings, and associations. When both paths cover the same event type, Activity sync overrides the corresponding Timeline setting to prevent duplicates.
The Timeline path has specific history rules. Sales emails, tasks, meetings, notes, and sales content views sync only after the contact is triggered to sync; earlier activities are not backfilled through that path. Record which mechanism is active before labeling an older interaction missing.
HubSpot: logging eligibility can change the denominator
HubSpot's contact email logging rules distinguish replies to existing logged threads from all emails involving known contacts. Addresses and domains on the never-log list are excluded from logging and contact creation. The documented new-contact creation option is a beta.
Inspect the selected rule and relevant exclusions with the administrator. A connection that is authenticated can still omit an incoming message under its configured policy. Keep that policy decision separate from a delivery failure.
Salesforce: normalize the objects created for an email
Salesforce's Sync Email as Salesforce Activity guidelines say that, when enabled, eligible captured emails become related Task and EmailMessage records, usable through standard reports and APIs. Its header-only option omits subject and body; exclusions and activity sharing rules also affect what is captured or visible.
An audit should identify the logical email across the related records. Adding the two object counts together would use the wrong unit. Verify whether this setting is enabled in the organization and which role is viewing the result. A timeline check under one user's access cannot establish every colleague's visibility.
These documented differences justify a configuration-specific demo. Use HubSpot vs Salesforce for the wider platform decision, then ask to trace one eligible interaction from source through the connector to its report.
Build a reconciliation ledger
Create one row per source interaction and retain every destination match. Use a read-only export or supported API retrieval with the permissions needed for the audit. Record extraction time, filters, pagination completion, and any inaccessible objects so an incomplete export cannot silently count as missing history.
| Ledger field | What to retain |
|---|---|
| Source identity | Source system, event key, activity type, thread or series key |
| Eligibility | Included, waiting, excluded, or unresolved, with a reason |
| Expected association | Confirmed contact and required account or deal IDs |
| Expected responsibility | Mapped actor, task assignee, or reporting user, as applicable |
| Content requirement | Required body scope, file references, or call outcome |
| Timing | Source occurrence, destination write, extraction cutoff |
| Destination evidence | Every matching logical activity and its object IDs |
| Review result | Missing, duplicate, wrong association, content gap, late, or pass |
Preserve the role of each user field. The sender of an email, the owner of a contact, and the assignee of a follow-up task can be different people. Only compare fields with the same meaning after applying the approved user map.
Before matching history to a consolidated contact, resolve retired identities using the CRM merge survivorship receipt. Otherwise, the audit may search only the new contact and miss an interaction still attached to an old identity.
Use separate checks for existence and usable content. A file reference does not prove the intended user can open the file. Where attachments matter, inspect the actual permitted test file and access path. If the policy intentionally excludes bodies or files, record that scope instead of declaring a content defect.
CRM activity sync audit: an executed reconciliation example
On October 23, 2026, we ran a Python standard-library exercise containing ten invented source events and eight normalized destination activity rows. Two source events are excluded by authored rules: one private-address case and one outside the selected history window. Eight events are eligible and due at the observation cutoff.
Download the replay script and complete inputs and results. Running python3 replay.py prints the committed JSON byte for byte. No vendor account, API call, real customer, or message send was involved.
The fixture assigns every eligible event a 15-minute arrival target. That number is an illustrative policy choice, not a vendor service guarantee. All eight deadlines precede the cutoff. Its destination rows already represent logical interactions, so the exercise does not count a related Task and EmailMessage as separate emails.
Equal totals conceal a missing event
| Source key | Destination evidence | Reconciliation result |
|---|---|---|
| mail:S01 | D01, expected fields | Pass |
| mail:S02 | D02 and D03 | Duplicate logical activity |
| mail:S03 | No match | Missing |
| mail:S04 | D04, contact C99 instead of C01 | Wrong customer association |
| mail:S05 | D05, user U99 instead of U01 | Wrong responsible user |
| mail:S06 | D06, required file F01 absent | Attachment reference mismatch |
| calendar:S07 | D07, expected fields | Pass |
| calls:S08 | D08, recorded after 25 minutes | Late against the authored target |
Eight expected events equal eight destination rows because the extra S02 row offsets the missing S03. Only seven distinct eligible source keys are present. Six eligible events have at least one exception; two pass all checks in the exercise.
S01 and S02 share a thread key but have different message keys. Deduplicating by thread would collapse two legitimate messages. S02's duplicate has two destination IDs referring to the same source event, so both matches remain in the receipt for investigation.
The fixture's excluded S09 and S10 have no destination rows, which is the authored expected result. A real audit should also check whether excluded activity leaked into the destination through manual logging, another connector, or a historical import.
What the result establishes
The result demonstrates a limitation of count-only reconciliation under a specific, inspectable set of inputs. It does not estimate the frequency of sync errors or compare product reliability. We deliberately inserted the exceptions, and the script checks those authored expectations.
It assumes complete exports, correct source keys, an agreed identity map, and comparable clocks. It does not test permissions, pagination, retention, connector retries, API failures, or repair behavior. Attachment checking compares fixture IDs only; it does not download a file or verify its contents. Use the exercise to agree a review procedure, then test the connector with your own permitted sample.
Diagnose each exception before repairing it
For a missing event, establish eligibility, deadline, and destination retrieval completeness first. Then trace source capture, integration receipt, identity matching, destination write, and association creation where the integration exposes those stages. Save the last confirmed stage and the supporting reference.
For duplicates, compare logical event keys and creation paths. Two CRM objects representing one email can be expected; two independently created logical activities may require repair. A repeated subject or similar timestamp alone is insufficient evidence to delete anything.
Wrong associations need an identity investigation. A shared mailbox, an employer change, or an unresolved duplicate contact may produce a plausible-looking match to the wrong customer. Correct the mapping and verify later events before treating the visible relink as a complete fix. Use the CRM data hygiene checklist for the broader record review.
Inspect field meaning before correcting an owner. A contact reassignment should not automatically rewrite the historical sender. If a user map is obsolete, preserve the event's actor while applying the intended current responsibility rule.
For late activity, compare occurrence, capture, write, and extraction timestamps using a consistent time zone. Decide how the audit handles source clock uncertainty and integrations that expose only a last-modified timestamp. A connector can eventually deliver everything and still miss the timing required for a sales handoff SLA.
Before replaying an uncertain write, check whether the destination already contains it. The email automation error recovery guide explains this retry distinction. Apply the actual connector's supported status and retry controls, and check whether re-logging history can trigger CRM automation or change a report.
Turn the audit into a release check
Choose a small, permitted sample containing an incoming reply, outgoing message, excluded interaction, activity with a file, and an event linked to a deal. Include calendar or calling cases only if those paths are in scope. This is deliberate case coverage, not a statistical sample for estimating a fleet-wide error rate.
- Agree expected results. Have the operational owner approve eligibility, identity, user mapping, content scope, and arrival targets before viewing the destination.
- Capture both sides. Preserve source evidence, all destination matches, extraction filters, access limitations, and integration configuration.
- Classify exceptions. Keep missing, duplicated, misassociated, incomplete, late, and unresolved items separate. An event may have multiple defects.
- Test the repair. Use supported test records, confirm downstream effects, and recheck the same keys after correction.
- Repeat after changes. Reconcile fresh events after a connector update, mailbox reconnection, user reassignment, or migration.
Set explicit stop conditions for a release: for example, an activity linked to the wrong customer or excluded content captured unexpectedly. Name who handles each queue and how long an unresolved case may remain open. Do not mark a missing source key resolved merely because total rows rose.
For a larger cutover, add this ledger to the CRM migration checklist. Include export access, reconciliation work, and exception review in the CRM total cost of ownership. A lower subscription price can still leave the team with more manual investigation.
Frequently Asked Questions
What is a CRM activity sync audit?
A CRM activity sync audit compares eligible source interactions with destination activities using event identity, associations, responsibility, content requirements, and timing. It also records intentional exclusions and unresolved cases so the expected population is explicit.
Why can CRM activity totals match while emails are missing?
An extra duplicate can offset a missing message. Different systems may also count threads, messages, or related database objects differently. Normalize the unit and compare source keys before accepting matching totals.
Should every mailbox email appear in the CRM?
Use the agreed logging policy. Excluded addresses, private interactions, unsupported paths, and historical import boundaries can affect eligibility. Audit excluded cases for unintended capture and investigate eligible messages whose arrival deadline has passed.
Can an activity timeline prove an email is reportable?
Verify the configured capture mechanism, underlying objects, report filters, and the viewer's access. Inspect the specific logical email through the report or retrieval path the business depends on. Timeline visibility alone does not establish every downstream use.
Should I replay all missing CRM activities?
First confirm the event is eligible, due, and absent through a complete destination retrieval. Use the connector's supported repair path, check for an earlier successful write, and review automation effects before retrying with permitted test data.
Next steps
Add a source-to-destination activity trace to your CRM requirements checklist. Bring one eligible message, one intentional exclusion, and one ambiguous customer match to the vendor demo. Ask to see the resulting timeline, associations, and report under the intended user's access.
Compare Pipedrive vs HubSpot for a sales pipeline versus broader platform decision, or HubSpot vs Salesforce when customization and administration are central. Choose the product and integration whose documented behavior and demonstrated audit trail fit the work your team can maintain.
