2,000 buyer groups and your search silently breaks

Salesforce B2B Commerce indexes only the first 2,000 buyer groups per product for search. Assign more and the surplus groups' buyers simply stop seeing that product in search and browse — no error, no failed job, just missing SKUs for some accounts and not others. Because a large brewer's outlet base is sliced into hundreds of price, assortment and promotional segments, you reach this hard limit long before the headline data-volume numbers suggest.

What actually breaks at 2,000 buyer groups?

Entitlements are how the platform decides which accounts can see and buy which products. You assign accounts to buyer groups, attach buyer groups to entitlement policies, and grant those policies access to products. Per the official entitlement limits page, two ceilings govern that model, and both are hard — Salesforce will not raise them through support (limits current as of March 2026):

The third row is the trap. The entitlement data will happily store more than 2,000 buyer groups against a product — the write succeeds. But during search indexing, the platform includes only the first 2,000 buyer groups for that product. Anything past that boundary still resolves correctly if a buyer arrives with a direct product URL or API call, yet never appears in search results or category browse. The catalog is technically correct and functionally invisible.

Why does a brewer hit this faster than the volume limits suggest?

The headline numbers are built to reassure. As documented in the same guide, a store supports up to 5 million buyer groups, and a buyer group up to 10 million accounts — both soft limits, increasable on request. Nothing in those figures hints that a single product can only carry 2,000 groups into search. Route-to-market segmentation is where the two scales collide.

Consider one flagship lager. It sells on-premise and off-premise, across a dozen regions, at several price tiers, to independent outlets and to national keychain banners, under returnable-deposit schemes that vary by market, and to a rotating set of promotional cohorts. Each axis is naturally modelled as a buyer group so that pricing and assortment resolve per segment. Multiply the axes and your best-selling SKU — the one every account wants — is entitled to well over 2,000 buyer groups. The products most central to your business are the first to cross the line.

Per account, the ceiling looks generous: the default is 20 buyer groups per account, soft and extensible. That is the number most teams check. But the 2,000 limit aggregates on the product side, not the account side, so account-level headroom tells you nothing about the exposure on your hero SKUs.

Why is the failure so hard to catch?

Nothing in the authoring experience objects. The policy saves. The data loads. The index rebuild reports success. The only signal is buyers reporting that products they are entitled to have gone missing from search — intermittently, by segment, in a pattern nobody can immediately reproduce. Sandboxes and test orgs rarely carry enough buyer groups to trip the limit, so it clears every pre-production gate and surfaces only at real-world scale.

Salesforce does warn you, in the muted register of a documentation footnote. Its own guidance on extending buyer entitlements per product reads:

[Extending this] can adversely impede search indexing.

It is a warning, not a guardrail. It sits next to the limit, not in the pipeline that would have stopped you. This is the same class of problem we have written about when governor limits quietly cap promotion logic — the platform enforcing a boundary your architecture never announced.

What it costs route-to-market

A missing SKU is not an abstract data-quality issue. It is a line that never reaches an order, a rep fielding a call about why an account cannot find your own beer, and a slow erosion of trust in the ordering channel your commercial team is trying to push volume through.

Promotions make it sharper. Spin up a temporary buyer group for a market activation, entitle the promoted product, and if that SKU already sits near its 2,000-group ceiling the new cohort falls off the index on arrival — the promotion is live, funded, and invisible to exactly the accounts it was built for. The failure mode rhymes with other platform ceilings we keep meeting: the loyalty engine whose limits arrive without warning, and WMS customisations that quietly vanish on upgrade. Different products, one lesson — the constraint you didn't model becomes the outage you didn't expect.

Where the fix has to live

The durable fix is to stop modelling every commercial nuance as its own buyer group on the same products. Collapse the entitlement graph to a small set of broad, stable groups, move price and assortment differentiation into pricing rules and a resolution layer that sits off the search-indexed path, and monitor buyer-groups-per-product as a first-class metric that alerts before 2,000, not after buyers complain. Where discovery must scale past what the platform will index, resolve it in a system you control — much of why our platform architecture keeps entitlement resolution on its own event-driven layer rather than inside the storefront's search index.

The 2,000-group boundary has not moved in years, and nothing suggests it will. As brewers push more trade-spend and assortment logic into digital ordering, the number of segments each hero SKU must serve only grows. The teams that come out ahead will treat entitlement scale as an architectural constraint to design around now — not a limit to discover the first time a national account cannot find their flagship lager.