Run distinct storefronts for different brands, entities, or branches from a single CommerceWeave installation. Shared or independent catalogs, pricing, inventory, and currency — configured per entity without code changes.
Before CommerceWeave
Managing separate commerce instances for multiple brands or locations means managing separate maintenance windows, separate integration points, and separate upgrade cycles for each. Shared operational knowledge and catalog content cannot be reused across instances.
With CommerceWeave
All entities operate from a single platform installation with centralized administration, shared component libraries, and consistent security controls — while maintaining the operational independence and brand differentiation each entity requires.
Each store in a CommerceWeave multi-store deployment has its own domain or subdomain, its own visual theme, its own navigation structure, and its own catalog and pricing configuration. A distributor running three regional storefronts can configure each with region-specific catalogs that reflect the inventory available in that region's warehouses, region-specific pricing that reflects local market rates, and region-specific content that speaks to local buyer priorities. Platform administration is centralized — a single admin login can access all stores within the installation — while each store's operational team can be granted scoped access that limits their visibility to their own store's configuration.
The multi-store architecture supports a spectrum of sharing configurations. A company running four brand storefronts for distinct product lines might share a common product catalog with brand-specific visual treatments, while maintaining entirely independent pricing configurations for each brand. A distributor with three regional branches might share catalog content but override inventory availability and warehouse assignment per branch. A manufacturer running both a B2B distributor portal and a B2C retail storefront might share catalog content while applying entirely different pricing, entitlement, and checkout configurations to each store. The sharing model is configured per entity pair, not applied as a global platform setting.
Currency configuration is applied per store, supporting organizations that operate commerce across multiple currencies without requiring separate platform instances for each currency market. Exchange rate management can be configured as manually-maintained rates updated by the finance team, automatically updated rates from a connected exchange rate service, or ERP-native rates where the ERP's currency table is the source of truth. For B2B organizations where pricing contracts are denominated in a customer's local currency, the real-time ERP price resolution applies in the configured store currency, ensuring that contract rates are served accurately regardless of the currency context.
Multi-store is implemented through the store entity model — each store has a store ID that scopes all configuration, catalog, and pricing data. API requests include the store context in the request header or path parameter. The Admin API supports bulk operations across multiple stores for configuration changes that apply at the organizational level. Shared catalog items are referenced by store ID join tables, not duplicated, ensuring that catalog content updates propagate to all stores that reference the shared item.
For multi-store rollouts, the AI copilot generates a phased rollout plan that sequences store launches by complexity and dependency, manages the configuration migration for each store, and coordinates test scenarios across all stores before go-live. For acquired business units being onboarded, the copilot maps the acquired entity's ERP data to the existing store model and proposes the sharing configuration.
AI Copilot — Available on Growth & Enterprise Plans
AI Copilot reduces implementation time for multi-store / multi-branch / multi-currency by automatically generating field mappings, test datasets, and validation scripts based on your ERP schema — so your team can ship faster without writing repetitive configuration code.
Book a Commerce Blueprint call and get a live walkthrough tailored to your ERP and business requirements.
| Area | Before | After CommerceWeave |
|---|---|---|
| Area 1 | Each brand or branch requires a separate platform instance with separate maintenance | All entities run from one installation with centralized administration and shared maintenance |
| Area 2 | Catalog updates must be applied separately to each instance | Shared catalog items update once and propagate to all stores that reference them |
| Area 3 | Multi-currency requires separate instances or complex custom middleware | Per-store currency configuration with ERP-native rate authority built in |
| Area 4 | Acquired business units require months of migration to the existing platform | Copilot-assisted onboarding maps acquired ERP data to existing store model |
B2B Account Portal & Role Management
Organizational hierarchies, role-based access controls, and approval workflows that turn your B2B storefront into a genuine self-service hub for buying teams of every size.
Contract Pricing & ERP Price Authority
Contract pricing, tier pricing, volume breaks, and customer-specific terms served in real time from your ERP — the single source of truth for every price your customers see.
Upgrade-Safe Extension Model
Before/after hooks on every major workflow, policy-driven overrides for business rules, and versioned extensions that survive every platform update without regression testing custom code.
Our Commerce Blueprint call delivers a written implementation roadmap specific to your ERP, your team, and your timeline.