Spare parts shop: show only parts for each machine

A Salesforce B2B Commerce store cannot filter spare parts by serial number out of the box. Entitlements decide visibility per buyer group, and hard limits rule out one group per machine. The way that works is a machine page: a custom component lists the machines registered to the dealer’s account and shows the parts for each, from Salesforce assets or live from PLM, with an add-to-cart button. Filtering the normal search per machine is possible through endpoint extensions, but the base class is still labelled Beta. The data matters more than the component: without an as-built parts list per serial number, no store can answer the question.

Why do entitlements not solve parts per machine?

In Salesforce B2B Commerce, which Salesforce now also markets as “Agentforce Commerce for B2B” according to Trailhead1, visibility works in a chain. A buyer account belongs to buyer groups, and Trailhead on the data model2 says that entitlement policies “define which products a buyer can see based on their buyer group memberships”. That answers “may this dealer buy this part?”, which is a question about the dealer.

“Does this part fit this machine?” is a question about the machine. A dealer with 40 installed machines from five series needs a different parts list for each one, and a seal that fits series A may also be orderable for series B as a spare. An entitlement says yes or no per product and buyer group, without a machine in between.

The obvious workaround is one buyer group per machine. The entitlement limits3 and the buyer group limits4 end that quickly:

2,000

buyer entitlements per product, hard limit

20

buyer groups per buyer account by default

30

buyer groups per buyer account with an Apex extension

During search indexing “only the first two thousand buyer groups for a product are included in the index”. A standard screw built into 6,000 machines would be findable for only a third of them. And a dealer with 40 machines fits neither limit per buyer account.

So entitlements stay what they are good at: which countries, tiers and brands may buy which parts. How to cut those groups is covered in buyer groups and entitlements.

Which data does a parts list per machine need?

Three sources, the same as for the spare parts agent by serial number:

• Installed base in Salesforce. The machine as an asset with serial number, account and machine type, ideally as an asset hierarchy with main assemblies. This is the anchor for the dealer: which machines are mine?
• As-built parts list from PLM. The bill of materials of the delivered machine, with the variants and revisions actually installed, and a flag for spare-relevant positions.
• Material data from the ERP. Material number, successor material and sales status. Prices and availability come into the store through the usual pricing and inventory route.

The third source is the one projects forget. A part that PLM lists as built in may have been superseded years ago. If the successor is not resolved before the store shows it, the dealer orders a part that no longer exists. Consumed parts on completed work orders also change the machine over time; why they belong in the system is explained in Field Service spare parts: ERP or Salesforce.

Option A: a machine page with its own component

The machine page is the option I would start with. A Lightning web component on its own store page lists the assets of the logged-in buyer’s account. The dealer picks a machine, sees its main assemblies and the spare-relevant positions, and adds parts to the cart. LWR stores, which Salesforce recommends for new stores, support only Lightning web components, according to the LWR migration guide5, so the component is built that way from the start.

Where the parts list comes from decides the effort:

• From Salesforce. Spare-relevant positions are stored per asset or per machine type, for example as child assets or a custom object. Fast and simple, but every position is a record to load and keep in step with PLM.
• Live from PLM. The component calls an Apex method, which calls a parts API in PLM or middleware for the serial number. No copy, always current, but PLM has to answer within the time a dealer waits for a page.

In both cases the component only shows part numbers. Whether the dealer may buy a part and at what price still comes from the store’s entitlements and pricing. A part that PLM lists but the dealer’s buyer group is not entitled to should appear as “on request”, not disappear without comment.

The advantage of the machine page: it does not touch the standard search or product pages, so Salesforce releases rarely break it. The drawback: dealers who type a part number into the search box still see every part their buyer group may buy, fitting or not.

Option B: filtering search and product lists per machine

Salesforce offers endpoint extensions for exactly this kind of change. According to the extensions guide6, they “modify the request and response of the Connect API endpoint” but cannot replace its default behaviour. The list of available extensions7 includes Commerce_Endpoint_Search_ProductSearch for product search and Commerce_Endpoint_Catalog_Products for product lists. An after method could remove from the response every product that is not in the parts list of the machine the dealer selected.

I would use this only as a second step, for three reasons:

1. Beta status. The Apex reference8 names the base class “BaseEndpointExtension (Beta)”, also for API version 67.0. Salesforce does not guarantee that beta features become generally available.
2. Distorted results. Search returns at most 200 results per page, according to the search limits9. If the extension removes 150 of them afterwards, the page shows 50, and in my assessment facet counts and total hits no longer match what the dealer sees.
3. Speed. Every search then needs the parts list of the selected machine. Without a cache in Salesforce, every keystroke ends in PLM.

A middle way avoids extensions: the machine page sets a search filter on an attribute such as machine series. That works only if parts carry the series as a filterable attribute and the series is precise enough. How attributes and synonyms for part numbers are set up is covered in B2B Commerce search by part number.

Who may see which machine?

This is the rule I would never relax: the dealer sees only machines registered to their own account. The serial number comes from the asset record shared with that account, never from a free text field. Otherwise one dealer reads the configuration of a machine another dealer sold.

On the licence side, Salesforce Help on Experience Cloud licences10 lists read, create and edit access to assets for Customer Community Plus and Partner Community. Which assets a buyer actually sees is a question of sharing. In practice that means: the asset’s account must be the buyer account, or the dealer relation must be modelled so that sharing follows it. Machines sold through a dealer but registered to the end customer need a clear rule before the store goes live. Which portal licence covers what in Manufacturing Cloud is described in the Manufacturing Cloud customer portal.

Worked example: 6,000 machines and 150 dealers

Assume a machine builder has 6,000 installed machines in eight series, 150 dealers and a PLM with as-built lists for machines delivered in the last ten years.

One buyer group per machine is ruled out by the limits above. One buyer group per series would mean up to eight groups per dealer, within the 20, but it only narrows the list to the series, not to the variant built into one machine.

The decision in the scenario: buyer groups stay per country and dealer tier. A machine page shows the dealer’s assets and calls PLM live for the spare-relevant positions of the selected machine; the result is cached on the asset for a day. For machines older than ten years, the page falls back to the parts list of the machine series and says so. Search filtering by extension is postponed until the class is generally available.

Trace 20 orders to the as-built list

1. 01

   Check the data first

   Take 20 recent spare part orders and test whether serial number, asset and as-built list lead to the part that was ordered.

2. 02

   Clean up the asset sharing

   Settle which machines belong to which dealer account, including machines sold to end customers.

3. 03

   Build the parts API before the page

   The parts desk can use it first; the store, the Field Service technicians and an agent can reuse it later.

4. 04

   Start with the machine page

   Consider search filtering only when dealers ask for it.

The chapter catalogue, search and entitlements of the B2B Commerce masterclass places this in the store design. Which system leads for which data is the subject of Salesforce integration.

Sources10

1. 1Trailhead (opens in a new tab)trailhead.salesforce.com
2. 2Trailhead on the data model (opens in a new tab)trailhead.salesforce.com
3. 3entitlement limits (opens in a new tab)developer.salesforce.com
4. 4buyer group limits (opens in a new tab)developer.salesforce.com
5. 5LWR migration guide (opens in a new tab)developer.salesforce.com
6. 6extensions guide (opens in a new tab)developer.salesforce.com
7. 7list of available extensions (opens in a new tab)developer.salesforce.com
8. 8Apex reference (opens in a new tab)developer.salesforce.com
9. 9search limits (opens in a new tab)developer.salesforce.com
10. 10Salesforce Help on Experience Cloud licences (opens in a new tab)help.salesforce.com