Harborline Media: 21,000 Duplicates Before a Launch
Harborline Media runs a two-way HubSpot–Salesforce sync across 140,000 contacts. Over eight months the database grew 31%, and a dedupe review now estimates 21,000 duplicate records. They come from three sources: webinar exports that use personal emails while the CRM holds work emails, a chat widget that creates a contact for every new visitor session, and a legacy trade-show import with no email normalization. Last quarter: 4,200 contacts received the same newsletter twice in one week; a merged record's contact owner reverted to the original import owner and the rep lost the account; a Salesforce field update pushed 600 contacts from SQL back to Lead; and 12 active lists show membership 15–30% higher than the contacts they should contain. The team wants to run the dedupe tool and merge everything before the Q3 launch in three weeks. There is no documented property dictionary, and five custom properties duplicate standard fields.
1. The team wants to run deduplication and merge everything in three weeks. What order of operations would you insist on, and why is merging first the wrong call?
Read the worked answer
Merging first fails on three counts. Merges are effectively irreversible in HubSpot - there is no unmerge - so a bad batch cannot be walked back. Merging before the intake is fixed means the duplicates regenerate within weeks, and you will do the whole exercise again. And merges change property values and list membership, which can fire workflow enrollment triggers, so a bulk merge during an active campaign is a duplicate-send risk rather than a cleanup.
Order I would insist on:
- Stop the inflow. Fix the chat widget so it does not mint a contact per session (and confirm consent handling), add email normalization to every import, and decide whether webinar personal emails are allowed to create records at all.
- Decide the identity rule: email is the unique identifier, so a personal-versus-work email pair is two people's data, not an automatic merge. Secondary email fields can link them without deleting either.
- Build a review queue sorted by confidence - exact email matches first, then name-plus-company, then domain heuristics - and review shared inboxes (info@, sales@) manually.
- Snapshot affected lists and workflow memberships, pause outbound automation and the sync, merge in batches, then re-verify.
- Only then re-enable automation and re-run the list audits. Three weeks is enough for steps 1, 3 and a first batch - not for all 21,000.
2. Explain how 600 contacts moved from SQL back to Lead after a Salesforce field update, how you would confirm the cause, and what guardrails you would add.
Read the worked answer
Mechanism. Lifecycle stage is a synchronized property. If the field-level sync for that property is two-way with Salesforce winning, then any Salesforce automation or validation rule that recalculates stage from a status picklist or a lead score will overwrite the HubSpot value on the next sync - including moving it backwards. A 600-record batch in one window strongly suggests a bulk update or a newly deployed rule, not organic contact behaviour.
Confirmation. Open property history on lifecycle stage for a sample of the affected records and look at the change source and timestamp; a source of 'Salesforce sync' clustered in one hour confirms it. Cross-check the sync health log for errors or field-level conflicts, and ask the Salesforce admin what shipped that week.
Guardrails.
- Name one system of record per stage band. Typically marketing owns up to MQL, sales owns SQL and beyond, and the property is set one-way in each direction.
- If true two-way is required, restrict which Salesforce fields can drive the stage and remove stage recalculation from Salesforce workflow rules.
- Add a monitoring workflow or report that flags backward stage movement above a threshold per day, so it surfaces in hours rather than at quarter end.
- Distinguish genuine disqualification (a lead legitimately recycled) from a bad overwrite before bulk-restoring the 600 - otherwise you will re-inflate the SQL count and corrupt the conversion rates you are trying to report.
3. Design the data-governance programme that prevents this recurring. Be specific about properties, intake rules, and cadence.
Read the worked answer
Property layer. Publish a property dictionary: name, definition, who owns it, allowed values, and system of record. Retire the five custom properties that duplicate standard fields by migrating values, freezing the old ones, then deleting - duplicate fields are how you end up with two competing lifecycle definitions. Mark the fields sales and marketing actually report on as required at the form or import-mapping level.
Intake layer. No import without a mapping template and a normalization step (lowercase, trim, strip plus-addressing where appropriate). Chat and forms should never create a record without an email; consider progressive profiling instead of asking for the same fields twice. Gate the highest-risk sources - trade show lists, purchased lists - behind a manual review.
Cadence. Weekly: review the duplicate queue for new pairs, since small and often beats an annual 21,000-record project. Monthly: audit 20 random records against Salesforce for field drift, and review the list-membership variance report for the 12 problem lists. Quarterly: reconcile contact counts, orphaned records with no owner, and bounced or invalid emails.
Ownership. One named owner for the contact object, with a documented merge policy (who may merge, at what confidence, and what gets checked first). Governance without an owner decays in about two quarters - which is roughly the timeline that produced this backlog.