How the Entitlement Data Model Works in Salesforce B2B Commerce (LWR)

In Salesforce B2B Commerce, Entitlements control who can see what across storefronts. They act as the data structure that determine what products are visible to a buyer group, and therefore an account within a store.

If you've configured B2B Commerce before, you're probably familiar with this concept, but do you know how the data is structured under the nice UI Salesforce provides? We'll dive into the data model in this blog!

1. Entitlement Objects

B2B Commerce Entitlements are primarily driven by the following objects:

• WebStore – Represents a storefront. Buyers only see stores they are entitled to access. A store may be connected to one or more catalogs and pricebooks.

• WebStoreBuyerGroup – Associates a webstore with a buyer group. Supports dynamically changing locales when buyers shop in orgs that are enabled for multiple languages and currencies.

• BuyerGroup – Logical grouping of accounts or contacts. This is the foundation of entitlement assignment.

• CommerceEntitlementBuyerGroup – Represents the entitlement policy for a buyer group.

• CommerceEntitlementPolicy – Represents an entitlement policy, which determines what products and prices a user can see.

• CommerceEntitlementProduct – Represents the entitlement policy for a product.

• Product – Represents a product that your company sells.

The Commerce Entitlement data model and how products are associated with account visibility

Together, these form a matrix that answers:

“Which buyer is allowed to access to view which products within a storefront?”

It's important to understand that several of these objects are what is called a 'junction' table in the Salesforce terminology. These junction tables allow, for example, multiple policies to be associated to a buyer group. Or multiple products associated with a policy. This gives us flexibility in how we use the entitlement policies.

2. How Entitlements Resolve During Storefront Load

When a buyer starts a session, the platform resolves their entitlements by looking at:

1. The Buyer’s Account/Contact → Buyer Groups

2. Buyer Groups → WebStore Entitlements

3. Buyer Group → Assigned Pricebook

4. Catalog + Product visibility rules from the same chain

3. Using the API to Retrieve products

One of the benefits of using the API's, connect API's, or the storefront API's is that the complexity we just discussed is handled automatically through these API's.

It's strongly encouraged that you use the API's instead of trying to reconstruct the logic and connections manually in Apex or in your JS.

Resource Example

https://yourInstance.salesforce.com/services/data/65.0/commerce/webstores​/0ZExx000000004rGAA/products?​effectiveAccountId=${accountId}&excludePrices=${true}&​excludeMedia=${true}&ids=${01txx0000006i44AII, 01txx0000006i44ACC, 01txx0000006i44ACC,…., 20th}&fields=${sku,name,productCode}

https://developer.salesforce.com/docs/atlas.en-us.chatterapi.meta/chatterapi/connect_resources_commerce_webstore_products.htm