Use this skill to configure a Salesforce B2B Commerce storefront: creating the WebStore, linking BuyerGroups, assigning CommerceEntitlementPolicies, and granting buyer contacts transactional access. Trigger keywords: B2B Commerce, WebStore, BuyerGroup, entitlement policy, buyer account, storefront access. NOT for B2C Commerce (LWR storefronts using Individual/Person Account models), CPQ quote configuration, or Order Management fulfillment flows.
This skill activates when a practitioner needs to configure or troubleshoot buyer access on a Salesforce B2B Commerce storefront — including WebStore creation, BuyerGroup assignment, entitlement policy linking, and granting individual contacts the ability to transact.
Gather this context before working on anything in this domain:
BuyerAccountAccess (contact-level role assignment) can log in and transact. Missing this step causes silent access failures that appear identical to entitlement misconfiguration.The complete access model is a chain of junction objects:
WebStore
└─ WebStoreBuyerGroup (junction)
└─ BuyerGroup
└─ CommerceEntitlementBuyerGroup (junction)
└─ CommerceEntitlementPolicy
└─ Entitled Product2 records
In parallel, buyer membership flows through:
Account (converted to BuyerAccount)
└─ BuyerGroupMember → BuyerGroup
└─ Contact (assigned Buyer or Buyer Manager role via buyer access record)
A buyer contact can only see and purchase products that are:
CommerceEntitlementPolicy linked to a BuyerGroupBuyerGroup is linked to the WebStore the contact is accessingAccount is a member of that same BuyerGroup via BuyerGroupMemberAll four conditions must hold. Missing any single link produces either a blank catalog or a login failure.
CommerceEntitlementPolicy has a hard cap of 200 BuyerGroups per policy. This limit cannot be increased via a support case; it is enforced at the platform level (B2B Commerce Developer Guide — Entitlement Data Limits).
A separate, less-documented limit applies at the store level: when a single Product2 record is entitled across more than 2,000 BuyerGroups within one WebStore, the Commerce search indexing engine silently stops indexing that product for buyer groups beyond the 2,000th. The product appears correctly in Salesforce admin and in the Commerce product catalog, but buyers in the affected groups see zero results in storefront search. There is no error log, warning email, or visible indicator in the UI that this cap has been breached.
Adding a contact to a BuyerAccount's associated Account record does not grant storefront access. Two explicit roles exist:
Role assignment is stored as a relationship record. If the role assignment record is missing, the contact can authenticate (if they have a Community or Experience Cloud user) but receives a "you are not authorized" error or an empty storefront with no cart access.
Before attaching BuyerGroups, the WebStore itself must have:
WebStorePricebook.Skipping these steps means BuyerGroup and entitlement wiring looks correct in data but the storefront remains non-functional.
When to use: Most straightforward setups — all buyers on the store see the same product catalog and pricing tier.
How it works:
BuyerGroup record (e.g., "Standard Buyers").WebStoreBuyerGroup with WebStoreId = your store and BuyerGroupId = the new group.CommerceEntitlementPolicy (e.g., "Standard Entitlement").CommerceEntitlementBuyerGroup linking the policy to the group.CommerceEntitlementProduct records linking each Product2 to the policy.Account to a BuyerAccount (set IsBuyer = true on the Account, or use the Commerce admin UI).BuyerGroupMember records for each BuyerAccount.Why not skip buyer group: Without a BuyerGroup, the entitlement policy has no path to the store. Products remain unentitled even if the CommerceEntitlementPolicy and BuyerAccount exist.
When to use: Different customer tiers need different product visibility (e.g., distributors see all SKUs, retail partners see a curated subset).
How it works:
BuyerGroup per tier (e.g., "Distributor Buyers", "Retail Buyers").WebStore via separate WebStoreBuyerGroup records.CommerceEntitlementPolicy per tier with the appropriate product set.BuyerGroup via CommerceEntitlementBuyerGroup.BuyerAccount to the correct group via BuyerGroupMember.Why not one policy with visibility rules: The entitlement model is additive; a contact with access to multiple groups sees the union of entitled products. Separate policies per group is the only way to enforce hard product-level segmentation.
| Situation | Recommended Approach | Reason |
|---|---|---|
| All buyers need the same catalog | Single BuyerGroup + Single EntitlementPolicy | Simplest model; easiest to maintain |
| Different buyers need different product sets | One BuyerGroup + EntitlementPolicy per tier | Only model that enforces hard catalog segmentation |
| Products missing from storefront search but visible in admin | Check 2,000 BuyerGroup-per-product indexing limit | Platform silently drops search indexing beyond cap |
| Contact can log in but sees empty catalog or no cart | Verify contact has explicit Buyer or Buyer Manager role | Account membership alone is insufficient |
| EntitlementPolicy limit error when adding BuyerGroup | Split groups across multiple policies | Hard cap of 200 BuyerGroups per policy; cannot be raised |
| Store search returns zero results after setup | Confirm search index has been rebuilt after entitlement changes | Entitlement changes do not automatically trigger re-index |
Step-by-step instructions for an AI agent or practitioner working on this task:
WebStorePricebook.CommerceEntitlementPolicy per tier. Verify the total number of groups per policy will not exceed 200.BuyerGroup record, then create the corresponding WebStoreBuyerGroup junction records tying each group to the WebStore.CommerceEntitlementPolicy, add CommerceEntitlementProduct records for the entitled Product2 records, then create CommerceEntitlementBuyerGroup junction records linking each policy to its BuyerGroup. Verify total BuyerGroup-per-product count stays under 2,000 across the store.IsBuyer = true on each customer Account (or use Commerce admin), then create BuyerGroupMember records assigning each BuyerAccount to the correct BuyerGroup.Run through these before marking work in this area complete:
WebStoreBuyerGroup recordCommerceEntitlementPolicy is linked to its BuyerGroup via CommerceEntitlementBuyerGroupIsBuyer = true and a BuyerGroupMember recordNon-obvious platform behaviors that cause real production problems:
Contact role assignment is mandatory, not inferred — Adding a contact to the Account that was converted to a BuyerAccount does not grant any storefront access. Only contacts with an explicit Buyer or Buyer Manager role assignment can transact. The failure mode is silent: the contact authenticates successfully but sees an empty storefront or receives an authorization error. This is the single most common misconfiguration in new B2B Commerce setups.
Entitlement changes do not auto-trigger search re-indexing — When you add or remove products from a CommerceEntitlementPolicy or add a new BuyerGroup, Commerce does not automatically rebuild the search index. The catalog admin reflects the change immediately, but buyers see stale search results until a manual or scheduled index rebuild completes. Always rebuild the index after any entitlement change and verify via a buyer-facing search before signoff.
Silent search exclusion above 2,000 BuyerGroups per product — If a Product2 is entitled across more than 2,000 BuyerGroups within a single WebStore, the search indexer silently stops including that product for groups beyond the 2,000th. No error is raised, no warning email is sent, and the product still appears correctly in the Commerce admin catalog. The only symptom is that buyers in the overflow groups see no search results for that product. This limit is documented in the B2B Commerce Developer Guide (Entitlement Data Limits) but is easy to miss in high-scale multi-group deployments.
| Artifact | Description |
|---|---|
| WebStoreBuyerGroup records | Junction records linking each BuyerGroup to the WebStore |
| CommerceEntitlementBuyerGroup records | Junction records linking each EntitlementPolicy to its BuyerGroup |
| BuyerGroupMember records | Records assigning each BuyerAccount to one or more BuyerGroups |
| Contact role assignments | Buyer or Buyer Manager role records for each transacting contact |
| Rebuilt search index | Post-setup index confirming all entitled products are searchable |