#B2B Commerce Cloud5 debatiendo

 Hi @padmini panigrahi

Yes, this is possible, but it requires a custom solution for translating Contact field values dynamically based on the user's selected language.

Salesforce B2B Commerce supports storefront translations, but changing the user's language does not automatically translate the existing values stored in Contact records.

You can consider the following approaches:

1. Use Salesforce Translation Workbench for supported field labels and picklist values.
2. For text field values, build a custom translation solution using Apex and an external translation API.
3. If you support a limited number of languages, maintain language-specific translations in custom fields or custom objects.
4. Use the user's selected language to display the appropriate translated values in your storefront without changing the original Contact record data.

Since you have many users across different regions and countries, I would recommend a custom translation layer that retrieves the appropriate translated values based on the user's selected language.

Official documentation: 

I hope this helps! If you find this answer helpful, please select it as the Best Answer. 

Thanks, 

Deepak Sachdeva 

Nubys Tech. Pvt. Ltd.

Hi @Pooja Wable

Variation products almost always go missing on a B2B Commerce (Lightning) store because of how the

Check in this order 

1. Category goes on the parent, not the variants. Assign only the Variation Parent to the category (Catalog → Category → Products). Variants shouldn’t be categorized, and the storefront shows the parent tile with attribute selectors. Also confirm that category’s catalog is assigned to your store (StoreCatalog).
2. Parent and variant setup.
   • Parent: Product Class = Variation Parent, IsActive = true, and the Attribute Set is assigned to the parent.
   • Variants: each has a ProductAttribute record pointing to the parent (VariantParentId) with values for every attribute in the set. A missing or blank attribute value can silently drop the variant.
3. Entitlement covers parent and variants. This is the most common miss. The policy must include the parent and every variant, be active, and be assigned to a Buyer Group. That Buyer Group must be assigned to the store, and the buyer’s account must be a member of it.
4. Pricing on the variants. Each variant needs an active PricebookEntry in a price book assigned to the store and Buyer Group. The parent doesn’t need a price, but variants without one won’t display or purchase correctly.
5. Search index. Run a full rebuild, not just an incremental update, and wait for it to finish. Changes to category assignment or entitlement often need the rebuild to appear.
6. Publish and test as the right user. If your store is LWR, publish the site after changes. Test as an actual buyer in the entitled account (not as an admin or guest), since guest users need their own Buyer Group and entitlement.

 Quick diagnostic queries  

-- Parent is active, has the right class, and is categorized
SELECT Id, Name, IsActive, ProductClass FROM Product2 WHERE Name = '<parent>'
SELECT ProductId, ProductCategoryId FROM ProductCategoryProduct WHERE ProductId = '<parentId>'
-- Variants are linked to the parent
SELECT Id, ProductId, VariantParentId FROM ProductAttribute WHERE VariantParentId = '<parentId>'
-- Entitlement covers parent AND variants
SELECT PolicyId, ProductId FROM CommerceEntitlementProduct WHERE ProductId IN ('<parentId>', '<variantIds>')
-- Variants are priced
SELECT Product2Id, Pricebook2Id, IsActive FROM PricebookEntry WHERE Product2Id IN ('<variantIds>')

If the parent appears in the query results but not on the storefront, the problem is almost always entitlement or the index. If the parent shows but variants don’t, look at the

records and variant pricing.   

I hope you find the above information helpful. If it does, please mark it as Best Answer to help others too.