RevOps Playbook: Deduplication, Identity Resolution, and Sync Error Recovery for HubSpot–Salesforce

Published by Bles Software, a custom software and AI company based in Yehud-Monoson, Israel, building web apps, AI agents and API integrations for clients in Israel, the US, the UK and the EU.

Duplicates and sync errors are not edge cases; they are an unavoidable byproduct of humans, integrations, and changing data. What separates healthy RevOps organizations from fragile ones is a deliberate identity strategy and an operational loop that detects, triages, and resolves data issues quickly. This playbook defines the policies and mechanics you need to keep HubSpot and Salesforce clean and convergent over time.

Identity: People and Companies

For people, use email as the primary key, enriched with system IDs. Store Salesforce Lead/Contact ID and HubSpot Contact ID on both sides. If a record’s email changes, retain a historical alias list so engagement history doesn’t split.

For companies, normalize website domain to a canonical form (lowercase, strip subdomains like www, remove trailing slashes). Create a deterministic hash of the normalized domain to power fast duplicate checks. If you rely on name matching, use it only after domain rules and require human review for merges.

Duplicate Prevention at Ingestion

Preventing duplicates is cheaper than merging. On HubSpot forms, check for existing contacts by email and associate to the right company by domain. In Salesforce, enforce duplicate rules that block or alert on exact and fuzzy matches for contacts and accounts. When a block is too disruptive, choose “allow but alert” and feed an Ops queue.

Merge Policy and Provenance

Define how merges are decided. A practical policy is to pick the survivor with the richest context (opportunities, recent activity, owner) and append fields from the duplicate where the survivor is blank. Record the provenance of the merge: who initiated it, which records were merged, and which fields changed. Keep a link to the archived duplicate for 30 days.

Error Classes and Triage

Group sync errors into classes: validation failures (required field missing, picklist mismatch), reference errors (missing parent account, missing owner), permission denials, and rate limits. Set an owner and SLA per class. For example, validation failures go to RevOps with a 1‑business‑day SLA; reference errors route to Sales Ops for account creation within 4 hours.

Retry and Quarantine

Use exponential backoff with jitter for automatic retries, and cap attempts (e.g., 6 tries over 12 hours). If the same error recurs, quarantine the record. Quarantine means the record is excluded from automatic sync until someone resolves the root cause, preventing retry storms.

Observability and Dashboards

Build an operations dashboard with leading indicators: error rate by class, duplicate creation rate by object, average time to resolution, and top recurring causes. Add a daily digest summarizing quarantined records and their owners. Observability transforms noisy exceptions into prioritized work.

Backfills and Replays

From time to time you will need to backfill corrections or replay missed events. Script these as idempotent jobs keyed by record ID and last‑updated timestamps. Keep every job dry‑run capable and log a summary (attempted, succeeded, failed) with links to error details.

Governance and Access

Restrict destructive actions like merges and mass edits to trained operators. Educate sellers on the impact of editing identity fields such as email or account name. When edits are required, provide guided flows that update related links and maintain history.

Continual Improvement Loop

Every month, review the top three error classes and propose a fix: improve field validation, tune mapping, adjust inclusion lists, or add a pre‑check before a risky action. Track before/after metrics so you can prove the integration becomes more reliable over time.

FAQ

Should we allow two‑way edits to identity fields?

Generally no. Allow edits in the system of record and write back to the other system, with a tie‑breaker based on last update time and origin. Two‑way free‑for‑all creates oscillation and duplicates.

How do we merge when both records have opportunities?

Pick the survivor based on ownership and recency of qualified opportunities. Re‑associate historical activities and ensure reporting roll‑ups are recalculated. Document merges that affect pipeline in a shared log visible to Sales.

What do we do with webform submissions that create dupes?

Use the email to attach activity to the existing contact. If the email domain indicates a different company, prompt RevOps to review and re‑associate the contact rather than auto‑creating another account.

How long should we retain duplicate archives?

Thirty days balances auditability and storage cost. Keep metadata longer (e.g., 90 days) for investigation while purging raw PII per privacy policy.

How can we reduce validation failures?

Align picklists across systems, mark required fields consistently, and add pre‑flight checks before creating or updating records. When a field fails often, make it calculated or controlled by automation instead of manual entry.