Magento 2 multi-store, scopes & B2B basics

One Magento codebase can run many storefronts. That capability — and the B2B module sitting on top of it — is a big part of why enterprises choose Magento. This post covers the scope model and the B2B basics.

The scope hierarchy

Magento organizes configuration and catalog into nested scopes:

• Global — the whole installation.
• Website — a top-level grouping; customers and carts are scoped per website.
• Store (or store view group) — groups store views.
• Store view — a single localized front end (one per language/currency presentation).

Configuration values cascade down: set a value at the website scope and child store views inherit it unless overridden. This is how you run, say, a US dollar store and an EU euro store from one backend.

Multi-store in practice

A typical setup:

• One website, two store views (en_US, fr_FR) sharing a catalog.
• Or multiple websites, each with its own catalog and pricing.

URLs can be subfolders (/fr/), subdomains (fr.store.com), or domains — controlled by the store's base URL and resolved at the web-server layer (Nginx, as Govard configures for pub/).

B2B basics

Magento's B2B module adds structures that SaaS carts usually charge extra for:

• Company accounts with hierarchies and team members.
• Shared catalogs — negotiated pricing per company.
• Quotes — buyers request a quote, sales negotiates, then converts to order.
• Approval rules — purchase orders routed for sign-off.
• Payment on account — invoicing instead of upfront capture.

These are configuration-driven, not custom-built, which is the whole point: the business logic is the platform, not your code.

What's next in this series

Catalog and scope are read paths; performance is the write path that users feel. Next we dig into the cache architecture — Varnish, Redis, and full-page caching.

Next in this series: Cache architecture — Varnish, Redis & full-page cache — /blog/magento2-cache-varnish-redis