Experience Studio
Experience Studio is where the catalog, the prices and the customer model become something a person can look at. Sites, themes, pages, media, forms and the transactional emails that go with them. If Commerce Studio answers what is true, Experience Studio answers what a buyer sees — and in B2B those two are rarely the same thing, because half the truth is only visible after login.
/experience prefix, in four sidebar sections: Dashboard, Surfaces, Build, and Extend and Develop.What lives here
Sites are the deployable storefronts. A site is a running frontend bound to your tenant's data — the standard Nuxt storefront, a theme on top of it, or your own build talking to the APIs. You can run more than one: a main shop, a spare-parts shop with a different navigation, and a per-market site are three common shapes. Each site decides which market and channel it reads from, which is how one catalog serves several audiences without duplicating a single article.
Domains connect a site to a hostname. shop.example.de or ersatzteile.example.de, with the certificate handled for you. A site without a domain is reachable but not yours; a domain without a site points at nothing. Both halves have to exist before a launch is real.
Themes carry the look: typography, colour, spacing, component styling. You install one from the theme marketplace, or you build your own. The important boundary is that a theme styles the shop — it does not decide what a page contains.
Pages and blocks decide that. A page is composed from blocks: hero, product grid, text, contact form, downloads. Blocks are what let a product manager change the landing page on a Tuesday without a release. Pages carry drafts, so the version you are editing is not the version a buyer is looking at until you publish.
Media is the storefront's own file library — the header image, the company brochure, the general terms as a PDF. Note the distinction from Commerce Studio's assets: a product datasheet that belongs to article 4711-A is a catalog asset and lives with the product. A brochure that belongs to the site lives here. Documents is something else: the coming document template engine for invoices and delivery notes, currently visible as a preview with disabled controls.
Forms collect what the shop cannot sell directly: a contact request, a callback, a sample order, a registration for a customer account. Each form has fields, a status, and a submission list you can work through. In German B2B a large share of real demand still arrives this way, from buyers who will phone afterwards regardless.
Messaging is the transactional mail: order confirmation, shipping notice, password reset, approval request. This is templates, the layouts that wrap them, a delivery log, a suppression list and the sending provider's configuration. It is not a newsletter tool — it is the mail your commerce processes emit, and when it stops, buyers assume the order did not arrive.
Storefront surfaces that come with the new apps
A page and a block are not the only things a buyer interacts with. Four further surfaces render inside your storefront, are configured elsewhere, and are documented in this Help Center at their 12-month state — the behaviour is described, the apps behind them are not on your tenant today.
| Surface | What the buyer does | Status | Documented in |
|---|---|---|---|
| Search UI | Types an article number, a manufacturer part number or half a description into the search box, and filters the result with facets. For most B2B buyers this is the entry point, not the category tree. | Planned — documented at its 12-month state | How search works · Autocomplete and suggestions |
| Configurator UI | Specifies a product that has no price until it is specified — length, material, connection — or works from a machine and an exploded drawing to the one part that broke. | Planned — documented at its 12-month state | Configure and order · Find a spare part |
| Quote request | Asks for a price instead of buying at one: a request from a product page or a whole basket, which arrives in your Innendienst as a quote to draft. | Planned — documented at its 12-month state | Handle a quote request |
| Approval submission | Submits a basket to their own purchasing rules rather than placing an order — cost centre, budget, approver — and waits. What they see afterwards is a request, not a confirmation. | Planned — documented at its 12-month state | Submit for approval |
All four follow the rule below, and the last one hardest: an approval flow only renders for a contact whose organization has cost centres and rules configured, and a quote button only appears for buyers permitted to request one. The storefront is the surface. The rules are in Commerce Studio.
The one idea that ties the Studio together: what renders depends on who is looking. Anonymous visitor, logged-in contact, contact with an approval role — three different pages from the same content, because visibility of prices, stock and order history is bound to the customer model in Commerce Studio.
The screens
| Screen | Path | What it does | Documented in |
|---|---|---|---|
| Dashboard | /experience/dashboard | Traffic and build KPIs plus shortcuts into every area. | Dashboard |
| Surfaces › Domains | /experience/domains | Hostnames, DNS status and what each one serves. | Domains · Guide |
| Surfaces › Pages | /experience/pages | The page list, with drafts and publishing. | Pages · Guide |
| Surfaces › Media | /experience/media | The site's own image and file library. | Media |
| Surfaces › Documents | /experience/documents | Document templates (invoice, delivery note) — a preview, controls disabled. | Documents |
| Build › Forms | /experience/forms | Form definitions and their submissions. | Forms · Guide |
| Build › Messaging | /experience/messaging | Transactional mail: templates, layouts, deliveries, suppressions, provider settings, audit and health check. | Messaging · Guide |
| Extend and Develop › Marketplace | /experience/theme-marketplace | Browse and install storefront themes. | Themes · Guide |
| Extend and Develop › Installed Themes | /experience/themes | The themes on your tenant and where each is live. | Themes · Guide |
| Extend and Develop › Sites | /experience/sites | Create, configure and deploy storefronts. | Sites · Guide |
| Extend and Develop › API & SDK | /experience/api | Reference for building a custom frontend. | API & SDK · Developer Portal |
Form submissions have no sidebar entry of their own — they arrive on the Forms screen's Form Requests tab.
Common tasks
- Create a storefront — the site itself, before anything is visible.
- Themes and branding — make it look like your company rather than a demo.
- Connect a domain — the step that turns a preview into a shop.
- Edit pages — the landing page, the category page, the Über-uns page.
- Forms and transactional email — contact forms in, order confirmations out.
- Storefront checks before you launch — the list worth walking through twice.
What is planned for this Studio
The Studio's own screens — sites, domains, pages, themes, forms, messaging — are not what changes. What changes is what a page can contain.
Four new surfaces arrive from apps configured elsewhere: the search UI with its facets and autocomplete, the configurator and spare-part finder, the quote request that replaces "add to cart" for goods you price individually, and the approval submission that turns a checkout into a request. Each is documented at its 12-month state: the behaviour is described here, the app behind it is not installable yet.
Two consequences are worth planning for now. First, your storefront stops having one checkout. A buyer with an approval rule, a buyer asking for a quote and a buyer ordering a listed article take three different paths out of the same basket, and the confirmation text for each is a different message — which makes this a Messaging question as much as a page question. Second, search moves to the centre. When the search UI arrives, the category tree stops being the main route into the catalog for most buyers, and the landing page you spent a week on is seen by fewer people than the search box beside it.
Nothing in your current site breaks. New surfaces are added to pages; they do not replace them.
How it relates to the other Studios
Commerce Studio owns the data; this Studio owns the presentation. When a product looks wrong in the shop, decide which side the fault is on before you start editing. A missing technical value is a catalog problem — the attribute is empty, or not scoped to this channel. A value that exists in the Cockpit but never appears on the page is a template problem. Product not visible in the shop walks the whole chain.
Prices resolve in Commerce Studio, but display is decided here. Whether a visitor sees a net price, a gross price, a "log in for your price" prompt or nothing at all is a storefront decision layered on top of the resolved price. A price that is correct in Check a price and wrong in the shop is nearly always a display or login-state question.
Markets and channels come from Commerce Studio. A site reads one market and one channel. Adding a language or a country is a change in Languages and markets that both Studios then act on.
Integration Studio delivers the mail and the leads. Messaging sends through a configured provider, and form submissions are typically pushed onward into a CRM by a workflow rather than worked through by hand forever.
Building on this Studio?
If you are writing code against it rather than working in it, the Developer Portal documents the same Studio for developers — APIs, SDKs and extension points.