HubSpot Salesforce Inclusion Lists: Setup, Sync Rules and Troubleshooting

A HubSpot Salesforce inclusion list, now called an inclusion segment, uses active membership to determine sync eligibility from HubSpot to Salesforce. Static lists cannot serve as this filter.

The practical question is which contacts your sales team needs in Salesforce. A newsletter subscriber, an active opportunity and an existing customer should not all be treated the same way. Agree that purpose before building the filter.

Updated 14 September 2026. This guide focuses on contact inclusion rules. For field mapping and the wider setup, see the complete HubSpot-Salesforce integration guide.

How to set up a HubSpot Salesforce inclusion list

In HubSpot settings, open the Salesforce app under connected integrations. Under Data sync, choose Contacts, then its sync rules. Find Limiting what syncs and choose your active segment. Save and select a newly created segment there if needed. HubSpot's setup reference

Before applying it to a live integration, I would run through these checks:

1. Write down who should qualify. Use named examples: a new enquiry, an unqualified subscriber, an open opportunity and an existing customer.
2. Inspect the segment. Check those examples against actual membership. A filter that looks right on screen can still include the wrong people.
3. Compare with records already in Salesforce. Identify customers and open opportunities that your new rules would exclude. Agree how those records should be maintained.
4. Test a small sample. Record the expected result, trigger the sync, and compare both sides before expanding the rollout.

For an eligible contact, use the Salesforce sync card's Actions menu to resync it. For a whole segment, use the resync action in CRM > Segments; this requires Marketing Hub Professional or Enterprise. HubSpot recommends budgeting at least three Salesforce API calls per record for a batch resync. Check the available allowance first. HubSpot's resync instructions

Troubleshoot contacts joining, leaving and rejoining

First-sync exception: Salesforce creation settings can create or initially sync a HubSpot contact outside the segment. Initial pairings can also write mapped fields back to Salesforce before membership is evaluated. Later updates require eligibility. See HubSpot's first-sync explanation.

The joining behaviour is documented in HubSpot's sync triggers. Keep your test results so the next person investigating an unexpected update can see what changed.

Inclusion lists and selective sync are different controls

Inclusion segments govern HubSpot-to-Salesforce eligibility. Selective sync controls the Salesforce-to-HubSpot direction. The available approach depends on the object. HubSpot's inclusion and object filtering reference

For Salesforce leads and contacts, HubSpot documents an approach based on the integration user's visibility and Salesforce sharing settings. Work through that with your Salesforce admin, including which other processes depend on the user's access. HubSpot's Salesforce selective-sync guide

I would document the two directions separately. It makes a failed sync much easier to investigate than a single instruction to "sync qualified leads".

Why syncing everything is the default mistake

Your HubSpot instance probably contains newsletter subscribers, old content downloads and event attendees who have never spoken to sales. Agree which of these records belong in Salesforce before expanding the sync.

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.

Reporting. A bloated Salesforce dataset can distort reporting built on lead and contact counts when those records do not reflect the pipeline sales actually works.

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.

Building the right list criteria

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.
• Exclusions with an owner. Review competitor, employee and suppression criteria with the relevant teams. Do not assume an email unsubscribe means every CRM update should stop. Decide how consent and suppression changes will reach Salesforce before excluding those records.
• A policy for existing relationships. Customers and contacts with open opportunities may need ongoing updates even when they no longer meet your new-lead qualification rules.
• 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.

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. Exclusions: agree competitor, employee and suppression rules with the relevant owners. Check the effect on customers, open opportunities and consent updates before applying them.
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.