B2B Commerce: agents, migration and rollout

Agents belong in a B2B store that already works. The Buyer Agent answers dealer questions about products, order status and reorders from the store’s data, and the Merchandising Agent helps maintain search, promotions and buyer accounts. Prices, credit and delivery dates still come from code and the ERP. Migrate an Aura store to LWR when features or growing custom code call for it, because there is no retirement date. Roll out in waves by buyer group, pilot dealers first. Measure per wave, and plan fixed regression tests for search, cart and checkout, because three Salesforce releases a year will touch all of them.

Where does the store stand after the first four chapters?

This chapter assumes what the previous ones described: a decision for Salesforce B2B Commerce from chapter 1, a catalogue with buyer groups and entitlements, customer prices and checkout on account, and an ERP integration that chapter 4 used to settle what is called live and who owns the order. Salesforce now also markets the product as “Agentforce Commerce for B2B” (opens in a new tab). The new name shows where Salesforce is taking it.

My order for the rest is still sober: first the store with the first dealers, then KPIs, then agents. An agent reads the same buyer groups, price books and order summaries as the storefront. If an entitlement is wrong, it shows the wrong part in the chat, just faster and in more convincing words.

The Buyer Agent and the Merchandising Agent today

Salesforce offers two kinds of agents for B2B Commerce. One talks to dealers, the other works for the team that runs the store. The dates Salesforce gives for them:

1. Jun 2026Buyer Agent generally available, with WhatsApp and SMS
2. Aug 2026Merchandising Agent for B2B, according to the innovations page
3. Jan 2027 · next dateCarter for Buyers: complete order in the chat with payment at contract price

Buyer Agent for dealers

You create the Buyer Agent from the template “Buyer Agent (B2B)”. According to Trailhead it searches products by name, category or specification, shows past and current orders with their status and reorders by copying a past order. Salesforce’s June 2026 blog post (opens in a new tab) lists it under “GA June 2026” and names WhatsApp and SMS as channels. The complete order in the chat, with confirmation and payment at contract price, is dated January 2027 on the Commerce innovations page (opens in a new tab) under the name Carter for Buyers.

The prerequisites are broader than the name suggests. Trailhead lists Agentforce Commerce for B2B, Service Cloud or Sales and Service Edition, the Agentforce and Einstein for Service add-ons, and Einstein generative AI with Data 360. If you run only Sales Cloud next to the store, you buy more than an agent. I found no separate price for the Buyer Agent on the official pages. How to estimate agent costs anyway is covered in the AI chapter on costs and tokens. Subagents, channels and licences in detail are in B2B Buyer Agent: ordering through WhatsApp and SMS.

For export dealers, language comes on top. Which languages Agentforce agents handle, what translation costs and how to keep knowledge per language is covered in multilingual Agentforce agents for export dealers. Check for the Buyer Agent itself which languages are released for your dealer countries.

Merchandising Agent for the store team

The B2B pricing page (opens in a new tab) lists Merchant Agent under Agentforce in both Growth and Advanced. The innovations page dates the Merchandising Agent for B2B to August 2026: it boosts or buries products in search, creates products and manages buyer accounts in conversation. The Trailhead unit on the merchandising skills (opens in a new tab) adds summaries of order value and conversion, and promotions from templates that a person reviews before they go live.

In a spare parts catalogue, boost and bury is the useful part: superseded part numbers down, successor parts and repair kits up. The search limits (opens in a new tab) allow 100 boost and bury rules per store, whether a person or an agent creates them. Material number, unit and sales status stay in the ERP or PIM. My table of what the agent may and may not change is in Merchandising Agent: what it does for a parts catalog.

Why must the agent never make up a price?

The second rule is about input. Every dealer message is text, and text can carry instructions. So I plan as if a filter will one day miss an injected instruction:

• The agent user reads only what the buyer may see.
• Actions that create orders or change data check permission, quantity and credit in code.
• No outbound action sends data to an address a dealer can influence.
• On WhatsApp and SMS the agent first has to know who is writing. The template brings a user verification subagent for this.

Attack patterns and countermeasures are in prompt injection in dealer portals, the general limits of agents in the AI chapter AI agents in manufacturing. If you keep dealer stock in Manufacturing Cloud, an agent can also propose replenishment. It becomes binding only once the ERP accepts it, see distributor inventory and replenishment with Agentforce. Other agents for manufacturers are placed in context in the chapter ERP, AI and rollout of the Manufacturing Cloud masterclass.

When is moving from Aura to LWR worth it?

Salesforce B2B Commerce has existed as a Visualforce package, as an Aura store and as an LWR store. According to the migration guide (opens in a new tab), only orgs enabled for Commerce before Spring ’23 can still create Aura stores, and Salesforce recommends LWR for new stores. There is no retirement date as of 27 October 2026: Aura stores are not on the list of active retirements (opens in a new tab). The same holds for B2B Commerce for Visualforce. Which generation you run is covered in B2B Commerce versions: Visualforce, Aura or LWR?.

The key differences (opens in a new tab) touch every piece of custom code: LWR supports only Lightning web components, styling uses --dxp styling hooks instead of custom CSS classes, data comes through wire adapters, and checkout is the built-in Salesforce Commerce Checkout instead of a flow. Salesforce documents no migration tool. So I plan the move as a rebuild of the storefront on the same commerce data.

Even if you wait, I would take the first step: replace Aura components in the running store with Lightning web components, because those run in both store types. Steps, checkout and the gaps in the guide are in Aura to LWR: migrating a B2B Commerce store.

Rolling out to dealers in waves by buyer group

A B2B store shows every dealer its own catalogue and its own prices. A big bang therefore shows every data error to every dealer on the same day. The data model makes waves easy: buyers reach the store through buyer groups, so a wave is the set of buyer groups you connect to the store.

• Pilot first. Dealers with many repeat orders of known parts, an honest contact person and few special conditions.
• Buyer managers at the dealer. According to Salesforce they get Customer Community Plus with B2B Commerce Super User and Delegated External User Administration. With that they create users for their own account, reset passwords and deactivate users without a ticket to your service desk.
• Test per wave. Entitlements, prices, stock, checkout and order status with a real buyer account of that wave, never only with an admin user.
• Inside sales stays available. Phone and email keep working. Dealers switch because the store is faster. When a pilot dealer phones in a reorder, the colleague walks them through the store once.
• Keep training short. One session per buyer manager on user administration and one page on searching by part number and reordering are enough to start.

Worked example: a compressor manufacturer sells spare parts to 250 dealers in Germany, Austria and Switzerland. Wave 1 brings fifteen pilot dealers in Germany into one buyer group in months 1 and 2. Wave 2 follows with the remaining German dealers in three groups by dealer tier, wave 3 with Austria, Switzerland and the key accounts with special conditions. Two weeks between waves are reserved for fixes. Wave 1 gets the Buyer Agent only after three months of ordering in the store. The full sequence is in B2B shop rollout to dealers. If dealers and inside sales have to change how they work, plan change management from the first wave.

Which KPIs show whether the store works?

Dealers order anyway. The question is whether they order through the store and whether that costs you less. I measure per buyer group, about three months after each wave:

KPI	Question behind it	Source
Share of order lines through the store	Are dealers switching?	ERP, with a channel flag
Zero-result searches	Do dealers find their parts?	Search analytics in Data Cloud
Conversion from search to order	Does finding lead to buying?	Search analytics, Merchant Agent
Inside sales minutes per order line	Does the store save work?	Own measurement, before and after
Orders needing manual correction	Is the data right?	ERP or order summaries

Salesforce announced search analytics in Data Cloud in July 2026 (opens in a new tab), with search queries, click-through rates, conversions and zero-result searches. It consumes Data Cloud credits, of which Growth includes 250K and Advanced 500K according to the pricing page. Salesforce does not publish the consumption, so look at the Digital Wallet after the first month.

Two things must be in place before go-live: a channel flag in the order interface so every line in the ERP can be traced to the store, and two weeks of time measurement in inside sales as a baseline. Without those numbers the business case stays a claim. Details and a sample calculation are in B2B shop KPIs: what to measure after go-live.

Running the store after go-live needs a regression list

Salesforce ships three releases a year, and each one touches storefront, checkout and extensions. I would keep a fixed regression list for the store that runs in the preview sandbox before every release:

1. Search by current and old part number, with ten typical parts.
2. Prices for one buyer account per buyer group, checked against the ERP.
3. Cart, reorder and checkout with a purchase order number through to the order in the ERP.
4. Order status and order history from the ERP.
5. Every custom extension and every custom Lightning web component.
6. If the Buyer Agent is live: a fixed test set of real dealer questions with expected answers.

Store configuration, meaning buyer groups, entitlement policies and price books, runs through the pipeline like metadata. How to place the three releases in a calendar is covered in the DevOps chapter on Salesforce release planning, how to introduce such a way of working step by step and measure it in the chapter on the rollout roadmap. I support pipeline and test automation as part of DevOps and release management.

First step: the store before the agent

1. 01

   Store before agent

   First wave live, data checked, KPIs collected. Then order status and reorder in web chat for the pilot group, WhatsApp only after that.

2. 02

   Clarify the store generation

   Aura or LWR, amount of custom Aura code, planned changes to checkout. That decides whether the migration comes before or after the rollout.

3. 03

   Cut the waves

   A dealer list with order lines, pricing logic and data quality, and from it the pilot and the following waves.

4. 04

   Measure baselines

   Channel flag in the ERP and inside sales time per line, before the first dealer orders.

5. 05

   Write the regression list

   Six items as above, kept in the client's repository.

All five chapters are on the masterclass overview page. If you need to decide which data between ERP, PIM and Salesforce belongs to whom, see how I help under Salesforce architecture.