HubSpot Salesforce Selective Sync and Inclusion Lists: When and How to Use Them

Almost every HubSpot-Salesforce integration I inherit is syncing every contact by default. Nobody chose this — it's just what the connector does if you don't actively configure otherwise, and turning it on with default settings is the fastest way to get a working demo. It's also the single most common mistake I fix, because "working" and "sensible" aren't the same thing here.

This piece is the deep version of something I only summarised in the complete HubSpot-Salesforce integration guide: why syncing everything is wrong by default, how inclusion lists actually work, the edge cases that catch people out, and a setup I'd default to if you don't already have a reason to do something different.

Why syncing everything is the default mistake

Your HubSpot instance almost certainly contains a large population of contacts who have no business in Salesforce: newsletter subscribers, people who downloaded one gated PDF two years ago and never engaged again, event attendees who scanned a badge, unsubscribed contacts you're still legally required to retain. None of them are sales-ready. All of them, under a default sync, become Salesforce records.

Three concrete costs to that:

API limits. Salesforce editions cap API calls in a rolling 24-hour window, and every create, update, and query the sync performs counts against it. Syncing your entire HubSpot database — including all the contacts who will never become pipeline — burns through that budget on records nobody's going to look at. On a large portal, this is the difference between a sync that keeps up in near-real time and one that queues and lags behind, because it's spending its allowance on noise.

Marketing contact costs. If you're on a HubSpot tier that prices marketing contacts, syncing doesn't change what you pay HubSpot — but it does mean your Salesforce user base is now working against a bloated dataset that doesn't reflect your actual addressable pipeline, which distorts anything built on top of contact or lead counts.

Noise for the people who have to use the org. This is the cost that actually gets escalated to me. A rep searching Salesforce for a prospect they just spoke to gets six results, four of whom are unrelated contacts who share a similar name and have never been sales-engaged. Multiply that across a sales team doing this daily, and the org stops being trusted — people start keeping their own spreadsheets again, which is exactly the drift a CRM integration is supposed to prevent.

None of this is really about a technical limit. It's about the fact that "sync everything" optimises for the easiest possible setup, not for the system anyone actually has to work in six months later.

Inclusion lists: how they work

An inclusion list is a HubSpot list — active or static, though active is almost always the right choice — that the sync configuration is scoped to. Instead of syncing "all contacts," you configure the connector to sync "contacts who are members of this list." Membership is the gate. Nothing else about the connector's behaviour changes; it's still the same field mappings, same sync direction, same object relationships. You're just restricting which records are eligible to cross over at all.

Building the right list criteria is the actual work here, and it's specific to your funnel — there's no universal answer, but there is a sensible starting shape:

• Lifecycle stage as a floor, not the whole filter. Gating on "Marketing Qualified Lead or above" is a reasonable baseline, but lifecycle stage alone tends to be too blunt — plenty of portals have stage inflation (contacts sitting at a stage their current activity doesn't support), and syncing purely off that inherits the inflation.
• A secondary qualifying signal. Combine lifecycle stage with something else that indicates genuine sales relevance: an explicit sales engagement action, a lead score above a threshold you've validated against real conversions, or membership in a specific campaign or product-interest segment if your business runs multiple motions.
• Explicit exclusions, checked before inclusion. Unsubscribed contacts, hard-bounced contacts, anyone under a GDPR suppression or "do not contact" flag — exclude these explicitly even if they'd otherwise qualify on stage or score. You don't want a compliance-suppressed contact showing up as an active Salesforce Lead because they happened to clear your MQL bar before they unsubscribed.
• A ceiling on staleness. Contacts who qualified a year ago and have had no activity since are a different case from contacts who just qualified. Whether you re-check staleness before initial sync, or handle it as an ongoing removal criterion, decide it deliberately rather than by accident.

Build the list, test it against a sample of records you already know the right answer for — "would a rep want to see this person in Salesforce, yes or no" — and adjust the criteria until the list matches your own judgement before you connect it to the sync.

Selective sync edge cases

Three things trip people up almost every time, and none of them are obvious from the setup screen.

Records falling out of the list. The intuitive assumption is that if a contact no longer matches the inclusion list criteria, they should stop being synced — maybe even get removed from Salesforce. That's not what happens by default. Once a record has synced, it generally keeps syncing on the mappings you've configured, regardless of whether it would still clear the list criteria today. List membership controls what starts syncing, not what keeps syncing. If you want records actively removed or unsynced when they fall out of qualification, that needs to be built deliberately — typically a workflow that acts on records leaving the list, rather than relying on the connector to infer it. Test this specifically; it's the single most common "wait, why is this still in Salesforce" support ticket I see.

Re-sync behaviour when a record re-qualifies. A contact drops off, re-engages six months later, and clears your inclusion list criteria again. Whether their existing Salesforce record picks back up cleanly depends on whether the original record still exists and is still correctly associated — if it was archived, converted, or merged in the meantime, re-sync can create a duplicate rather than resuming the original. Worth testing this scenario explicitly rather than assuming it, especially if your sales team manually archives or reassigns stale Leads.

Orphaned records. When a synced record's HubSpot side gets deleted, merged, or its owner changes in a way the sync wasn't built to handle, you can end up with a Salesforce record that no longer has a clean HubSpot counterpart — or vice versa. These don't error loudly; they just sit there, technically present, functionally disconnected from whichever system should be updating them. Periodic reconciliation — checking for Salesforce records that reference a HubSpot ID which no longer exists, and the reverse — is the only real defence, and it's worth building as a recurring check rather than a one-off cleanup.

How this interacts with Salesforce sharing rules

Inclusion lists control whether a record is eligible to sync. Salesforce sharing rules control whether the integration user is allowed to write it once it clears that gate — and these are independent systems that don't know about each other.

The integration user needs edit access to whatever queue, territory, or owner assignment a newly-synced record would land in. If your Salesforce org has territory-based sharing, or restricts Lead visibility by region or team, a record that passes your inclusion list criteria cleanly can still fail to sync — not because the list logic is wrong, but because the integration user hits a sharing rule wall. This shows up in the error log as a permissions or access error, which looks unrelated to list membership and gets misdiagnosed as a connector bug more often than it should.

Practical implication: when you build or change an inclusion list, check it against your current sharing model, not just your qualification criteria. A list that's logically correct can still produce a wave of permission errors if nobody cross-checked it against how Salesforce restricts access for the records it's about to create.

A sensible default setup

If you're setting this up without a strong existing reason to deviate, here's what I'd start with:

1. Gate: Lifecycle stage = Marketing Qualified Lead or above, AND (lead score above your validated threshold OR explicit sales engagement logged).
2. Hard exclusions, checked first: unsubscribed, hard-bounced, GDPR-suppressed, marked as competitor or existing employee.
3. Removal handling: a workflow that flags — doesn't necessarily delete — records that fall out of qualification for 90+ days, for manual review rather than automatic removal.
4. Sharing check: confirm the integration user has write access across every queue, territory, and owner assignment records from the list could land in.
5. Review cadence: revisit the list criteria quarterly. Sales-readiness signals drift as your ICP, funnel, and go-to-market motion change, and a list tuned for last year's funnel quietly stops matching this year's.

This isn't a universal answer — your actual funnel and business model should shape the specifics — but it's a defensible starting point that avoids the two failure modes I see most: syncing too much noise, and building exclusion logic so complex nobody can maintain it after the person who built it moves on.