# Product Tailoring for B2B

Product Selections answer which Products a buyer can see. [Product Tailoring](/api/projects/product-tailoring.md) answers a different question: how those Products appear to that buyer. The same Product can carry a different name, description, image, or slug for one buyer than for another, without creating a second Product to maintain.

In B2B this matters because buyer organizations often need their own presentation of a shared catalog: a buyer-specific product name, a contract reference in the description, or imagery that matches the buyer's context. Tailoring lets you keep one canonical Product and vary its presentation per Store. For how those canonical Products and Variants are modeled in the first place, see the [Model your product catalog](/learning-model-your-product-catalog/product-modeling/overview.md) path.

## What Tailoring overrides

A Product Tailoring belongs to a specific **Product and Store combination**, and overrides selected presentation data for that Store only. Use the API reference for the exact fields on [ProductTailoringData](/api/projects/product-tailoring.md#producttailoringdata) and [ProductVariantTailoring](/api/projects/product-tailoring.md#productvarianttailoring).

Tailoring is **selective**: you override only the fields that need a Store-specific value. For example, if you tailor only the `name` for the Commercial Store, the Store projection returns the tailored `name` and falls back to the original Product values for fields such as `description` and `slug`.

The following request tailors only the `name` of one Product for the Commercial Store, and publishes it immediately. Because `description` and `slug` are not included, the Store projection returns their original values from the Product.

```http
POST /{projectKey}/product-tailoring HTTP/1.1
Content-Type: application/json

{
  "store": { "typeId": "store", "key": "pacific-commercial-store" },
  "product": { "typeId": "product", "key": "zen-rack-server-9000" },
  "name": { "en-AU": "Commercial-grade Rack Server 9000" },
  "publish": true
}
```

You retrieve the result through the [Get ProductProjection in Store](/api/projects/productProjections.md#get-productprojection-in-store) endpoints, not through a normal Product query: tailored information is only surfaced in the Store-scoped projection.

## Tailoring is not Localization, and not a Product Selection

Three mechanisms sound similar but solve different problems. Keeping them distinct is the core architectural skill on this page:

- **Product Selection** controls **availability**: whether a Product appears for a Store at all.
- **Localization** controls **language**: the value of a field across locales (`en-AU`, `de-DE`) within a single Product.
- **Product Tailoring** controls **presentation per Store**: a different value of a field for one Store versus another.

They compose rather than compete. A tailored field is still a `LocalizedString`, so you can tailor a Store-specific name and still localize it across languages. And Tailoring never makes a Product visible: if a Product is not available in the Store through an active Product Selection, tailoring it changes nothing a buyer can see.

Tailoring changes presentation, not availability. When you use Product Selections, the tailored Product must still be available in the Store through an active selection, or the buyer will not see it at all. This connects directly to the inactive-selection behavior from the previous page.

## Staging and publishing

Like a Product, a Product Tailoring has staged and current data. Use staged data to prepare Store-specific presentation changes, then publish the Tailoring when those changes should appear in Store projections. For the exact publication behavior, see [Stage and publish tailored product information](/api/projects/product-tailoring.md#stage-and-publish-tailored-product-information).

For B2B design, the key point is that Product publication and Tailoring publication are separate decisions. Unpublishing the Tailoring makes the Store projection fall back to the original Product presentation, while Product publication still controls whether the current Product Projection can be retrieved.

## Constraints to design around

Product Tailoring carries constraints that affect B2B modeling:

- **Model Tailoring as Store-local.** A Tailoring belongs to one Product and one Store. If two Stores need the same tailored values, plan for separate Tailorings. See the [Product Tailoring reference](/api/projects/product-tailoring.md) for the exact resource relationship.
- **Keep search requirements separate.** Tailored information is not indexed for Storefront Search APIs and cannot be used in Query Predicates for Product Projections. For discovery requirements, model the original Product data accordingly.
- **Treat Product keys and Store lifecycle as ownership boundaries.** Tailoring depends on the Product `key`, and deleting a Store removes associated Product Tailoring data.
- **Check Project limits before scaling Tailoring broadly.** For large buyer-specific catalogs, compare the number of required Tailorings against the [Product Tailoring limit](/api/limits.md#product-tailoring).

Because tailored information is not indexed for search, a buyer's faceted catalog search and filtering run against the original Product data, not the tailored values. Use Tailoring for presentation of a Product the buyer has already found, not as a mechanism to change how Products are discovered.

## When to reach for Tailoring in B2B

Tailoring is the right tool when a buyer needs a **different presentation of a shared Product**: a buyer-specific product name, a description that references their contract, or imagery matched to their context. It is the wrong tool when the requirement is really about **availability** (use Product Selections) or **price** (use Channels and pricing, covered in the next module). Reaching for Tailoring to solve an availability or pricing problem leads to duplicated effort and a catalog that behaves unexpectedly in search.

For Zen Electron Trade, a fitting use is presenting the shared `zen-rack-server-9000` Product to Pacific Property Group's Commercial Store under a commercial-grade name and with commercial imagery, while Horizon Hotels continues to see the standard presentation, all from one underlying Product.

## Key takeaways

- Product Tailoring varies a Product's presentation (name, description, slug, meta, images, assets) per Store without duplicating the Product.
- Tailoring is selective: untailored fields fall back to the original Product values.
- Tailoring controls presentation, Product Selections control availability, and Localization controls language; they compose rather than replace each other.
- A tailored Product must still be available in the Store through an active Product Selection, or the buyer sees nothing.
- Tailoring is one-per-Product-and-Store, not shareable, not search-indexed, tied to the Product `key`, and removed when its Store is deleted.

## Related pages

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