Buyer groups and entitlements: who sees which product

In Salesforce B2B Commerce, a dealer sees a product when the dealer’s buyer account belongs to a buyer group, and that buyer group has an entitlement policy containing the product. Prices follow the same path through price books assigned to the buyer group. Product visibility is therefore a question of how you cut buyer groups. My recommendation for manufacturers: build groups from country, dealer tier and brand, keep their number small, and never create one group per dealer. The limits of 20 buyer groups per account and 2,000 buyer groups per product in the search index punish that design later, when the store is live.

How does product visibility work in B2B Commerce?

Salesforce B2B Commerce, which Salesforce now also markets as “Agentforce Commerce for B2B” (Trailhead1), controls access through a chain of standard objects. The Trailhead unit on how buyers access a store2 sums it up in one sentence: “Buyers are connected to stores using buyer groups.”

• Buyer account: a normal Account that is enabled for buying. Its contacts become buyers or buyer managers.
• Buyer group (BuyerGroup): bundles buyer accounts that share settings. Each membership is a BuyerGroupMember record.
• Store assignment (WebStoreBuyerGroup): connects a buyer group to a store.
• Entitlement policy (CommerceEntitlementPolicy): links buyer groups to products. According to the data model overview3, it carries the fields CanViewProduct and CanViewPrice.
• Buyer group price book (BuyerGroupPricebook): assigns price books to buyer groups.

Visibility and price therefore hang on the same buyer groups. That is why I design both together. How the price side works, and when prices should come live from the ERP instead, is covered in customer prices in B2B Commerce.

20, 200 and 2,000: the limits that shape the design

Salesforce documents the limits for buyer groups and buyer accounts4 and for entitlements5 on two pages. Soft limits can be raised through Salesforce support, hard limits cannot. The ones that matter for a manufacturer, as of October 2026:

Limit	Value	Type
Buyer groups per buyer account	20	soft
Buyer groups per buyer account with the Apex buyer group extension	30	soft
Buyer groups per entitlement policy	200	hard
Buyer entitlements per product (buyer groups a product is entitled to)	2,000	hard
Products per entitlement policy	3 million	soft
Entitlement policies per org	105,000	hard
Accounts per buyer in the Account Switcher	200	soft

For the 200 buyer groups per policy, Salesforce warns that going beyond capacity “can lead to data scaling issues”. The Account Switcher limit matters for dealers with many branches: one buyer who orders for more than 200 accounts needs a custom switcher, and the standard one fails at 2,000.

Why not one buyer group per dealer?

The idea is tempting because it mirrors the ERP: every customer has its own conditions, so every customer gets its own buyer group, its own policy and its own price book. With 50 dealers this works. The arithmetic changes with size:

• A spare part that every dealer may buy is entitled to as many buyer groups as there are dealers. At 2,000 dealers, every common part hits the search limit.
• A policy such as “all spare parts” serves at most 200 buyer groups. With 1,000 dealer groups you need at least five copies of the same policy and have to keep them identical.
• Every new dealer means a new group, new policy assignments and a new price book assignment. Onboarding becomes a data project.

Individual prices are rarely a good reason for individual groups. At manufacturers with SAP or a similar ERP, net prices usually come from conditions per customer. Those belong either in a live price call or in a small number of price books per tier, not in one price book per dealer.

Cut buyer groups by country, dealer tier and brand

I build buyer groups from attributes that change rarely and that the ERP already holds in the customer master:

1. Country or sales organisation. It decides assortment, language, currency and legal restrictions such as export control.
2. Dealer tier. For example service partner, sales partner or end customer. It decides the price book and sometimes visibility, such as service parts only for certified partners.
3. Brand or product line, when dealers sell only one brand.

Entitlement policies then follow assortments, not customers: “spare parts general”, “spare parts for service partners”, “consumables”, “accessories brand B”.

Worked example: a manufacturer with 800 dealers in 12 countries, three dealer tiers and two brands. Country and tier give 36 buyer groups, the two brands two more. Each dealer account sits in two groups, well below 20. A common spare part is entitled to 36 groups instead of 800, and the policy “spare parts general” serves 36 groups instead of hitting 200. A new dealer means two memberships and no new policy.

Exceptions stay exceptions. If one dealer needs a special part for a special machine, a small “special agreements” group is fine. Showing every dealer only the parts for the machines it owns is a different problem, which buyer groups do not solve. I describe the options in show only parts for each machine. And if countries or brands differ so much that catalogue or checkout differ, the question becomes one store or several.

When do rules beat manual upkeep?

Memberships and policy assignments are data that someone has to maintain. Salesforce offers two ways to assign by rule.

Apex buyer group extension. The extension point Commerce_Domain_BuyerGroup_EvaluationService is described in the list of available extensions6 as a way to “dynamically assign users to buyer groups by executing custom Apex business logic”. Your code could read country and tier from the account at runtime. The Apex reference7 names the condition: assignments may not take effect immediately while caching is active, so Salesforce asks you to disable the Salesforce CDN and Edge Network, sandbox first. For a store with dealers on several continents I would measure page load times before I accept that.

Qualification rules from Revenue Management. According to Salesforce Help8, these rules “dynamically evaluate the product visibility for buyer groups based on their account data” and replace manually maintained entitlement policies. They require a Commerce Growth or Advanced licence plus Revenue Cloud Advanced. If sales already runs Revenue Cloud, that is worth a look. For visibility alone I would not buy it.

My default is simpler: the integration sets memberships from the ERP customer master, for example in a nightly job that maps country and tier fields to buyer groups. That is easy to test and easy to explain to the business. Rules only pay off when the number of combinations keeps growing.

First step: the entitlement concept on one page

Write the entitlement concept on one page before anyone loads data:

• the list of buyer groups with the criteria that put an account into each group,
• the list of entitlement policies with the assortment each one covers,
• a matrix of which group gets which policy and price book,
• a count against the limits above, for today and for three years from now.

The ERP fields that drive membership then go into the interface list. This page is the first deliverable of the chapter on catalogue, search and entitlements in my B2B Commerce masterclass. Whether dealers then actually find the parts they are entitled to depends on search, covered in finding parts by part number. Reviewing such concepts before a partner builds is part of my work on Salesforce architecture.

Sources8

1. 1Trailhead (opens in a new tab)trailhead.salesforce.com
2. 2Trailhead unit on how buyers access a store (opens in a new tab)trailhead.salesforce.com
3. 3data model overview (opens in a new tab)developer.salesforce.com
4. 4buyer groups and buyer accounts (opens in a new tab)developer.salesforce.com
5. 5entitlements (opens in a new tab)developer.salesforce.com
6. 6list of available extensions (opens in a new tab)developer.salesforce.com
7. 7Apex reference (opens in a new tab)developer.salesforce.com
8. 8Salesforce Help (opens in a new tab)help.salesforce.com