What you’re working toward.
A field ownership contract, controlled sync population, and recoverable error queue.
- Bring these people
- Administrators from both CRMs and the shared revenue-process owner
Have these inputs ready
- Administrators who can inspect both sides of the integration.
- Required fields, validation rules, duplicate rules, and user mappings from both systems.
- A pilot set including a lead, a converted contact, and an account with an opportunity.
Agree the boundary
List which teams work in each CRM and which records they need. Specify who creates leads, who qualifies them, and which system owns opportunity stages and commercial values.
- Name which system creates and owns each business decision: marketing qualification, sales ownership, opportunity stage, and commercial value.
- Draw the contact/lead, company/account, and deal/opportunity relationships. Include what happens when a Salesforce lead converts rather than treating it as an unrelated new person.
A shared record-and-process boundary signed off by both teams.
Map the shared model
Compare required fields, picklist values, record owners, and relationships. Document a field-level source of truth and how conflicts should resolve. Confirm connector eligibility and supported mappings in current documentation.
- For every mapped field, record direction, conflict rule, valid values, blank behavior, and the permitted writer. Resolve required-field mismatches before the pilot.
- Test updates originating on both sides. Include a blank value, an unmapped dropdown option, an inactive owner, and a change blocked by a validation rule.
A field contract with concrete pass/fail examples.
Control enrollment
Start with a limited record population. Review how filters, duplicate rules, validation rules, and missing users affect records before opening a broad sync.
- Define the HubSpot-to-Salesforce inclusion criteria and the Salesforce-to-HubSpot selective-sync approach separately. Confirm the controls available for the objects and integration version in use.
- Include a record entering and leaving the permitted population. Check the effect on future updates and existing records rather than assuming exclusion deletes historical copies.
A documented enrollment boundary and a tested offboarding behavior.
Operate the integration
Test creation, updates from both sides, disqualification, and owner changes. Maintain an error queue with an accountable owner and reconcile representative records after configuration changes.
- Assign someone to review errors by cause: missing permission, invalid value, duplicate, validation failure, or exhausted capacity. Capture both system IDs with every issue.
- After fixing a rule, retry a bounded affected set and reconcile the result. Audit changes to mappings and inclusion criteria so recurring failures can be traced to a configuration change.
An owned error queue, retry procedure, and configuration change log.
A field-level ownership contract
Illustrative ownership choices; your teams must approve the actual direction and conflict handling.
Know when the work is ready.
Use these checks in the handover. Keep evidence of the result and assign an owner to anything that still fails.
- Create and update tests pass in both approved directions.
- Lead conversion preserves the expected person and account relationship.
- An excluded record behaves as documented.
- Errors can be identified, assigned, corrected, and retried without a blanket resync.
Catch the problems early.
One filter does not describe both directions
HubSpot inclusion segments and Salesforce selective sync address different boundaries. Record both before approving the population.
Competing automation creates a value tug-of-war
Two individually correct workflows can repeatedly overwrite each other. Resolve ownership at the field level.
Product references
HubSpot documents inclusion segments for records syncing toward Salesforce and points to selective sync for the opposite direction. Available object controls depend on the sync setup.