Even though both CRMs allow multiple associations, the native sync won’t allow these multiple associations to pass through. Even when I manually fix the meetings on either side, the sync won’t work while multiple are associated.
But, we often have multiple attendees in our meetings, and don’t want to lose the data on the Hubpsot side by limiting it to one contact association. This would mean that attendees would lose the meeting association, affecting other properties and automations (like ‘next activity date’, which we use heavily)
This looks more like an association-model limitation than a meeting sync issue.
I probably wouldn’t try to force the native connector to handle it. I’d keep the standard sync in place and handle the missing associations separately through the API — much cleaner than rebuilding the integration.
If you want, DM me — happy to compare the HubSpot/Salesforce object setup with you.
Native Salesforce sync is built around a simpler association model than HubSpot’s multi-association engagements. Multiple contact associations on a meeting are valid in HubSpot (and often in Salesforce via WhoId / related lists), but the native sync bridge usually will not carry “N attendees on one meeting” both ways. That matches what you are seeing: fix it manually, leave multiple associations, and sync still will not reconcile cleanly.
Practical ways teams keep the HubSpot automations without fighting the sync:
Pick a sync shape for meetings. Decide HubSpot is source of truth for multi-attendee meetings. Sync a primary contact association (organizer or first attendee) for Salesforce reporting, and keep the full attendee list only in HubSpot. Trying to make native sync own every attendee association is what usually breaks.
Protect next activity date (and similar) on the HubSpot side. Drive those properties from HubSpot workflows / calculated engagement activity against the contact, not from a Salesforce-mirrored meeting that lost associations. If Salesforce must show activity too, sync a single primary meeting link or a rollup field, not the full multi-association graph.
Do not expect manual multi-association repairs to survive sync. While native sync is active on that object, re-associating multiple contacts on either side often gets overwritten or ignored on the next pass. Pause sync on that engagement type while you test, or accept primary-only for synced meetings.
If you truly need N associations in both systems, that is outside native sync today. You need a custom associations write (API / middleware) that upserts each contact-meeting association deliberately, with HubSpot or Salesforce clearly owning the write so the two connectors do not thrash.
Quick check that helps the next reply: are you on the native Salesforce integration (Settings → Integrations → Salesforce) or a Data Hub / custom sync path, and is the pain on Meetings only or also Calls/Tasks?