Blogs

Running multi-brand ecommerce on one Salesforce platform

Multi-brand ecommerce on one Salesforce platform means every brand keeps its own look, content and range, while the code underneath is built once. For a group with several webshops, it stops paying for the same feature twice. It also asks the brands to agree on more than they are used to.

Three fashion brands running on one shared Salesforce storefront codebase

Key takeaways

1

One shared codebase ends duplicate builds and technical debt between brands.

2

Brand identity lives in content, styling and range, which stay separate.

3

The hard part is governance: brands must decide together what gets built.

Heading 1

Heading 2

Heading 3

Heading 4

Heading 5
Heading 6

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.

Block quote

Ordered list

  1. Item 1
  2. Item 2
  3. Item 3

Unordered list

  • Item A
  • Item B
  • Item C

Text link

Bold text

Emphasis

Superscript

Subscript

The decision on the table is whether to consolidate separate brand sites into one white label setup, a shared storefront that each brand branches off. The upside is permanent: every feature is built once. The cost is also permanent. Each brand gives up some freedom to change its site on its own schedule.

Why separate brand sites drift apart

Brands that grow up on separate codebases drift, even on the same platform. One brand gets a newer payment integration, another a better back-end structure, a third a different content system. After a few years the group runs several webshops that share a vendor and little else.

That drift has a price. The development team maintains every version in parallel. A feature requested by one brand gets rebuilt when a second brand asks for it months later. Technical debt piles up unevenly, and the most advanced brand sets expectations the others cannot meet without their own project.

How a white label setup works on Salesforce B2C Commerce

A white label product is built once and sold under several brand names, like a supermarket's own-brand range made by one supplier. In ecommerce, the principle is the same. One storefront codebase carries the shared functionality, and every brand site is a configuration of it on the Salesforce Commerce Cloud (Agentforce Commerce) platform.

Brand identity does not live in the code. It lives in what shoppers actually see, and that stays separate per brand.

  • Each brand keeps its own content, imagery and campaigns.
  • Styling, typography and colour palette are set per brand on top of shared components.
  • Catalogue, pricing and promotions stay under each brand's own control.
  • Brand-specific features can still run behind a feature toggle per site.

The same principle scales to a headless front end, where shared components serve several brands through one API layer, as set out in headless commerce with the Composable Storefront.

What we did for Cool Investments

Cool Investments owns three fashion brands: Coolcat, America Today and MS Mode. All three ran on Salesforce Commerce Cloud, on the same realm, yet each had been built separately. Over time their order management, product information management and content creation had grown apart, and features were built brand by brand.

A Commerce Cloud architect at FORWARD first mapped the differences between the three sites and planned the technical route to a single white label. The implementation itself took four months. Senior developers from FORWARD and Cool Investments did the technical work, while the ecommerce, data, CRM, IT and purchasing teams each had a part in it. We migrated all three brands before the busiest commercial period in fashion.

Priscilla Calemi
Marketing & Community Manager

Brand identity does not live in the code.

Priscilla Calemi

|

Marketing & Community Manager

What changes after consolidation

The clearest change is how features ship. At Cool Investments, a new product detail page went live for all three brands at once, where it would previously have been built for one. The thinking behind that page type is covered in product detail page best practices.

The cost logic changes with it. Before consolidation, the cost of a feature grows with the number of brands that want it. After, it is built once and configured per brand, so each extra brand adds little. The consolidation itself is the one-off cost: analysis, alignment of integrations and data, and migration. Even a project stopped halfway leaves value behind, because a mapped set of differences and a cleaned-up integration landscape are useful on their own.

When a shared platform is the wrong call

A white label setup fits brands that sell in a similar way: comparable checkout, similar fulfilment, overlapping features. It fits less well when one brand sells subscriptions and another sells one-off purchases, or when one serves consumers and another serves trade buyers with account pricing. Forcing those onto one codebase moves the complexity into toggles and exceptions.

It also demands a way of working across the group. The brands have to decide together what goes into the shared storefront, and someone has to own that roadmap and say no when a request only serves one brand. Groups without that governance get the constraints of a shared platform without the speed.

Plan integrations before the storefront

Integrations are where consolidation gets expensive. Payment providers, order management and product information systems often differ per brand. Aligning them, or at least putting a common layer in front of them, sets the pace of the whole project. Payment is a good place to start, and the trade-offs are covered in choosing a payment service provider.

Customer data follows the same logic. Accounts, loyalty and consent can be shared across brands or kept apart, and that choice has legal as well as commercial consequences. Settle it with the data and CRM teams at the start, because moving customers from one model to another after launch is slow and visible to shoppers.

Explore Commerce Cloud
About the Author
Priscilla Calemi
Marketing & Community Manager

Our insights

Button Text
No items found.
No items found.
No items found.