# Resource clustering: a unifying model

You already met Product Selections, Stores, and Channels in the [Model your business structure](/learning-model-your-business-structure) learning path, where you used them to run separate brand sites and regional assortments. In B2B, the same three resources compose to answer a single question: **what does this buyer see, and on what commercial terms?** This page is a refresher on how they fit together, framed as one unifying model you will apply for the rest of the module.

The useful mental model is **clustering**: each resource groups a different set of entities, and a Business Unit's commercial context is the result of stacking those groups together.

## What each resource clusters

Each of the three resources clusters a different kind of entity:

- **Product Selections cluster Products.** A Product Selection is a named subset of the Project's catalog: the Products a particular assortment should contain (or exclude). On its own it is just a list; it has no effect until a Store uses it.
- **Stores cluster the commercial context.** A Store groups the buyer-facing resources that belong together: its Product Selections, its Carts, Orders, and Customers, and the Channels it trades through. A Store is the boundary that a Business Unit is attached to.
- **Channels cluster Products and Orders with pricing and supply.** A Channel of role `ProductDistribution` scopes which prices apply, and a Channel of role `InventorySupply` scopes which inventory is counted. Channels are how the same Product carries a different price for a different buyer.

A simple way to hold the three apart: Product Selections decide **which** Products, Channels decide **at what price and from what stock**, and Stores are the **container** that binds a buyer to a specific combination of both.

## How they compose in B2B

In B2B, the composition has one extra link compared with B2C: the **Business Unit** resolves to a Store, either directly or through inherited Store configuration, and that Store gives a buyer organization its scoped catalog and pricing.

```mermaid
flowchart TD
	BU[Business Unit<br/>the buyer] -->|resolves to| S[Store<br/>commercial context]
	BU -.->|optionally clustered by| CG[Customer Group<br/>secondary buyer cluster]
	S -->|uses| PS[Product Selections<br/>which Products]
	S -->|trades through| CH[Channels<br/>which prices and stock]
	PS -->|cluster| P[Products]
	CH -->|scope pricing on| P
	S -->|cluster| CO[Carts, Orders, Customers]
	CG -.->|can scope| PR[Prices and Discounts]
```

Reading the diagram from the buyer down: a Business Unit resolves its Store (directly or by inheritance, as covered in Module 1). That Store determines the assortment through its Product Selections, the prices through its distribution Channel, and the order and customer data that belongs to the buyer. Change the Store a Business Unit resolves to, and you change all three at once, which is why the Store is the unit of B2B commercial configuration.

This composition is what lets two buyers on the same Project see two different catalogs at two different prices without duplicating a single Product. The Products are shared; the Selections, Channels, and resolved Store differ.

## Customer Groups: a secondary clustering layer

The three core resources cluster Products, prices, and the commercial context through the Store. A Customer Group adds an optional secondary layer that clusters buyers directly, without routing through a Store.

A Customer Group tags a set of Customers or Business Units so they share pricing or discount treatment. In B2B, Channels on the Store are the preferred way to scope negotiated pricing, because the scope follows the buyer's commercial context automatically. Reach for a Customer Group when a seller wants to group buyers together directly, for example tier-one and tier-two buyers who each receive a different rate, without giving each tier its own Store.

A Customer Group is the right secondary cluster when:

- Several buyers should share a pricing or discount tier that is independent of their Store assignment.
- You want to segment buyers for a Cart Discount or a Customer-Group-scoped Price without duplicating Stores or Channels.

Because a Customer Group binds to the Customer or Business Unit rather than the Store, it cuts across the Store-based clusters instead of nesting inside them. For how Customer Groups compete with Channels in price selection, see [Price versus discount](/learning-model-b2b-commerce/configure-b2b-pricing/price-versus-discount.md).

## Matching requirements to resources

When a B2B requirement lands on your desk, the first architectural move is to decide which resource in the cluster owns it. The following table maps common requirements to the resource that solves them.

| Requirement | Resource that solves it |
| --- | --- |
| "This buyer should only see a subset of our catalog." | Product Selection (mode `Individual`) on the buyer's Store |
| "This buyer should see everything except a few restricted lines." | Product Selection (mode `IndividualExclusion`) on the buyer's Store |
| "This buyer pays negotiated prices different from list." | Channel (`ProductDistribution`) on the buyer's Store, with scoped prices |
| "This buyer's orders and carts must be separate from others." | Store, which clusters Carts, Orders, and Customers |
| "This buyer should see a different product name or image." | Product Tailoring (covered later in this module) |
| "Two buyers share most of a catalog but differ at the edges." | A shared Product Selection plus a buyer-specific one on each Store |
| "Group several buyers into a shared pricing or discount tier without separate Stores." | Customer Group on each buyer's Customer or Business Unit |

Notice that several requirements resolve to the Store, because the Store is the resource that the others hang from. When you are unsure where a requirement belongs, ask which entity needs to be clustered (Products, prices, or transactional data), and the resource follows.

## Key takeaways

- Product Selections cluster Products, Channels cluster Products and Orders with pricing and supply, and Stores cluster the whole commercial context including Carts, Orders, and Customers.
- In B2B, a Business Unit resolves to a Store, directly or through inherited Store configuration, and that Store scopes the buyer's catalog and pricing.
- Changing the Store a Business Unit points at changes its assortment, pricing, and transactional data together.
- The composition lets multiple buyers see different catalogs at different prices while sharing the same underlying Products.
- Customer Groups add an optional secondary layer that clusters buyers directly, useful for shared pricing or discount tiers that cut across Stores; Channels remain the preferred scope for negotiated B2B pricing.
- To place a requirement, decide which entity must be clustered (Products, prices, or transactional data), and the owning resource follows.

## Related pages

- [Area overview page with navigation](/learning-model-b2b-commerce.md)
- [Previous page: Overview](/learning-model-b2b-commerce/design-b2b-catalogs/overview.md)
- [Next page: Company-specific Product catalogs](/learning-model-b2b-commerce/design-b2b-catalogs/company-specific-product-catalogs.md)