How storefronts work
A storefront looks like one thing to a buyer and is four things to you. Getting those four apart is what stops the question "where do I change this?" from having a different answer every week.
Four layers, one website
| Layer | What it is | Who changes it | How often |
|---|---|---|---|
| Site | The deployed application: the code, the build, the running server | A developer, or a push to a Git branch | Per release |
| Theme | The design system and templates the site renders with: colours, type, product tile, listing page, header, footer | You, through the theme's settings | Rarely, then never |
| Page | One addressable piece of content: /about-us, a campaign landing page, a service page | You, in the visual editor | Weekly |
| Block | One element inside a page: a hero, a text block, a product teaser, a table | You, in the visual editor | Daily |
The rule that follows: the further down the table, the more freely you may change it. A block is disposable. A theme is a decision you live with. A site is a deployment.
A storefront is also not a place where product data lives. No description, price, stock figure or category sits in the storefront. It reads all of that at request time from the catalog, the price lists and the customer record. That is the single most important thing to internalise, because it means the answer to "the product looks wrong in the shop" is almost never "fix the shop".
Where the content stops and the catalog starts
Draw the line like this:
- Editorial content lives in the storefront, in Pages: service descriptions, campaign copy, the hero on the homepage, the contact page.
- Product content lives in the catalog: names, attributes, images, datasheets, categories. The storefront only renders it.
- Commercial content lives in pricing: prices, scale prices, contract prices, terms. It is resolved per buyer, per request.
When somebody asks you to "put the new datasheet on the shop page", they are asking for a catalog change. Doing it as a page change (a PDF dropped into a text block) is how a shop ends up with two versions of the same document and no idea which is current.
How the catalog and prices reach the page
Three mechanisms decide what a given visitor sees.
Channels decide which products exist for this storefront. A channel has a setting for what happens to products nobody has explicitly assigned to it. Visible (open) shows the whole catalog. Hidden until assigned (closed) shows only what has been assigned, which is the negotiated assortment a punchout contract describes. Open is right for a public shop. Closed is right for a customer portal.
Markets decide in which language, currency and tax context. A market carries its locales, its currencies and its tax classes. See Languages and markets.
Price lists decide what the number is, and whether there is a number at all. A price list can be restricted to a single account, to a channel, to a validity window, or to logged-in buyers only.
Each of the three can hide a product independently. That is why a product not appearing in the shop has more than one plausible cause and is worth a checklist rather than a guess.
One tenant, several storefronts
You do not get one shop. You get as many as the business has distinct fronts, and the usual reasons for a second one are:
- A second brand. Two companies under one roof, two logos, one warehouse.
- A second country.
.deand.chwith different tax handling, different currency and a different assortment. - A closed customer portal next to the public shop, with prices only after login and a much smaller catalog.
- A spare-parts shop whose whole job is finding one part fast, sitting beside a normal product shop.
What they share and what they do not:
| Shared across storefronts | Separate per storefront |
|---|---|
| Products, attributes, families, categories | Which products are visible (channel) |
| Assets and datasheets | Theme, logo, colours, page content |
| Customer accounts and contacts | Domain and URL structure |
| Order and quote handling | Language, currency, tax (market) |
| Users and roles in the Cockpit | Price lists that apply |
Why a B2B storefront is a working tool
This is where B2C intuitions do the most damage. The buyer on your shop is at work. They are not browsing, they are not discovering, and they are not being persuaded. They know the part number, they have a requisition to close, and the shop is competing with the fastest alternative they have: phoning your Innendienst, who finds it for them in under a minute.
Four consequences:
Prices are often not public. In B2B the list price is rarely the price, and your competitor's buyer is not entitled to see what your customer pays. A price list can be marked logged-in buyers only, and anonymous requests skip it entirely. So an anonymous visitor may see a catalog with no prices at all, on purpose. See What buyers see before they log in.
The catalog is per customer. Two logged-in buyers on the same URL can see different products and different prices. Frame every storefront question as "for whom?" or the answer will be wrong.
Re-ordering beats discovery. Most B2B orders are repeats. Order lists, past orders and a field that takes part numbers straight into the basket carry more revenue than any campaign banner. Design the homepage of a logged-in buyer accordingly: it is a dashboard, not a shop window.
Search is the product. A buyer who cannot find article 4711-A in two
attempts phones instead, and you have paid for a shop that did not save anybody
any work. See
Search and product discovery.
How this works in the Revenue Cloud
The Experience Studio holds the whole storefront layer:
- Sites: the deployed storefront applications, their builds and their deployment history.
- Marketplace and Installed Themes: themes you install for the tenant and activate on a domain.
- Domains: every hostname, what it serves, its DNS and TLS state, and its access protection.
- Pages and Media: the editorial content and the asset library.
- Forms and Messaging: enquiries in, transactional mail out.
Channels, markets and tax classes are commerce settings that several storefronts share, so they live under Commerce Studio › Configuration rather than in the Experience Studio.
Next
- What buyers see before they log in: the B2B-specific half of the model.
- Create a storefront: from nothing to something you can preview.
Understand storefronts
What a storefront is made of, and the B2B specifics: hidden prices, customer-specific assortments, and a shop that is a working tool rather than a shopping experience.
Logged in vs. not
Hidden prices, customer-specific assortments and login-gated price lists: the part of a B2B storefront that has no B2C equivalent.