RevOps Playbook: Two‑Way Sync QA, Error Handling, and Troubleshooting 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.
A strong RevOps function treats the HubSpot–Salesforce integration like production infrastructure: observability, runbooks, and predictable incident response. This playbook shows how to verify two‑way sync end‑to‑end, catch issues early, and resolve them fast without creating downstream data debt.
QA Philosophy: Test Like a User, Verify Like an SRE
Your QA should simulate real user journeys and then validate the system state with precision.
- Scenario‑based: Walk realistic lead flows—form fill, hand‑raise, event reg, partner referral, SDR reply—through to Opportunity creation.
- Assertions: Verify mapping, directionality, lifecycle state, ownership, campaign membership, and a handful of calculated fields.
- Observability: Watch integration error logs, platform health indicators, and API limits while scenarios run.
Codify this approach so anyone can run the suite and interpret results.
The Core QA Suite (Starter)
Run these scenarios in sandbox first, then in production with labeled test records.
- Inbound Demo: Submit a form with unique email and clear UTM values. Expect HubSpot to set Lifecycle to Lead → MQL, Salesforce to create a Lead, and routing to assign an owner. Confirm UTM mirrors in Salesforce and Campaign Member creation.
- Content MQL: Progress a nurture contact beyond score threshold. Ensure Salesforce Lead Status promotes and HubSpot captures the reason.
- Event -> Opportunity: Register and attend an event; associate Campaign. Create an Opportunity in Salesforce and verify HubSpot lifecycle becomes Opportunity and influence is recorded.
- Disqualification Loop: Disqualify a Salesforce Lead with a reason. Confirm HubSpot lifecycle regresses appropriately and the reason mirrors.
- Ownership Change: Reassign in Salesforce and see the owner mirror to HubSpot within your SLA.
Capture evidence (screenshots, payload snippets) for each step and store it with your mapping matrix.
Error Taxonomy and Runbooks
Categorize errors so responders know where to look and how to fix.
- Permissions and FLS: Missing field‑level permissions for the integration user.
- Validation/Enums: Picklist value not allowed, validation rule blocked.
- Missing Parents: Company/Account or Campaign not found when creating a child record.
- API/Limits: Daily limit reached, request throttled.
- Network/Transient: Temporary outages or timeouts.
For each category, maintain a runbook with:
- Symptoms and common log messages.
- Reproduction steps and scope checks.
- Fix steps (grant permission, add translation, create missing parent, retry window).
- Backfill guidance and verification queries.
Store runbooks in your repo and link them from alert notifications.
Monitoring and Alerting
Turn on integration error dashboards and route alerts to a shared RevOps channel.
- Volume and Trend: Total errors per day, by category, and by object.
- Latency: Average time from HubSpot change to Salesforce reflect (and vice versa).
- API Health: Remaining limits, error rate, and retry queues.
Set thresholds that trigger human review but avoid alert fatigue. For example, any spike 3× the seven‑day average or a sustained error rate over 2% for an hour.
Picking Apart a Failure: A Forensic Checklist
When a ticket arrives (“this record didn’t sync”), follow a consistent path:
- Identify the record in both systems (by email/ID). Confirm existence and last modified timestamps.
- Check integration logs for the window around the change. Identify the first error, not the noisiest symptom.
- Inspect field‑level permissions and picklist values for the field that failed. Verify translation or defaulting rules ran.
- Look for parent references: is the Company/Account or Campaign missing on the target side?
- Review validation rules introduced since the last successful sync.
- Confirm API limits and retry behavior; manual retries may be queued.
Document the root cause and whether a guardrail should be added.
Backfills Without Collateral Damage
Backfills are sometimes necessary—make them surgical.
- Narrow Scope: Filter by updated‑since timestamp, specific cohorts, or a single object type.
- Sequence Carefully: Backfill parent objects before children.
- Verify in Batches: Process small batches, verify success rate and values, then proceed.
Always record the time window, filter, and counts in your change log.
Preventing Recurrence
Incidents should strengthen the system.
- Add a unit check: a validation or translation rule that blocks the bad state next time.
- Extend observability: a new metric or alert that surfaces this failure earlier.
- Improve the runbook: clearer symptoms, faster fixes, and explicit backfill instructions.
Close incidents only after the prevention step is merged.
Enablement and the Human Layer
Many sync “bugs” start as human process drift. Educate teams to reduce noise.
- Provide a one‑page guide: what fields do what, who owns them, and how long syncs take.
- Publish a “known issues” list with workarounds.
- Offer an intake form for mapping or field requests that routes to RevOps.
People will follow the process they understand; ambiguity breeds errors.
KPIs for Operational Excellence
Track the operational side of integration health:
- Mean Time to Detect (MTTD) and Mean Time to Repair (MTTR) by error category.
- Sync success rate by object.
- Percentage of opportunities created with at least one campaign association.
- Ratio of prevented duplicates to discovered duplicates (higher is better).
Review KPIs monthly and tie improvements to roadmap items.
FAQ
Why do we see “insufficient access rights on cross-reference id” errors?
The integration user lacks permission to see or edit a parent record (Account, Campaign) referenced by the change. Grant field‑level access, ensure sharing rules include the record, or create the parent first. Add a pre‑check that verifies parent existence before child creation.
How can we spot picklist mismatches before they break sync?
Maintain a jobs that samples mapped picklists weekly and compares value sets. Alert when a new value appears on one side. Add a translation rule or expand the allowed set before the next release.
What’s the safest way to reprocess failed records?
Retry in small, labeled batches with filters (IDs or updated‑since windows). Verify one batch end‑to‑end, then continue. Avoid reprocessing the entire object class unless the failure was a transient outage.
We keep hitting API limits—what should we change?
Reduce sync scope with inclusion lists, debounce noisy updates (batch changes where possible), and schedule heavy jobs during low‑traffic windows. If usage is truly required, consider purchased limit increases, but optimize first.
How do we handle validation rules that conflict with marketing data?
Either meet the validation in HubSpot before sync (translate/default), or carve a narrow exception for the integration user with strong logging and a time limit. The approach should be documented and approved in governance.
More RevOps Playbooks from Bles Software
- Attribution & Pipeline Reporting Setup | Bles Software
- Data Mapping Checklist (Leads/Contacts/Opportunities) | Bles Software
- Field Governance & Picklists | Bles Software
- Sync Rules: Deduping, Owners, Lifecycle | Bles Software
- HubSpot ↔ QuickBooks Integration Playbook | Bles Software
- Errors & Retries: Top Fixes | Bles Software
- HubSpot ↔ Salesforce Integration: Executive Guide | Bles Software
- HubSpot ↔ Salesforce: Cost & Timeline Drivers | Bles Software
- Daily AI Roundup: AI agent, model and enterprise AI news