Dealer Marketplace: Adobe Commerce or CWS Platform for Catalog, Network, and Service Operations?

Editorial note: an architectural comparison of Adobe Commerce and the CWS Platform for a dealership marketplace. Every fact about Adobe Commerce comes from its public documentation, linked alongside the relevant statement.

Adobe Commerce and the CWS Platform place architectural weight in different areas when a dealership network builds an official parts portal. Adobe Commerce organizes websites, stores, store views, and transactional capabilities within a commerce hierarchy, allowing catalog, cart, shipping, and payment capabilities to be separated or shared based on the configured scope, as shown in its multiple websites documentation. The CWS Platform starts with the distributed commercial operation: technical fitment, source-level availability, regional preference, assisted selling, and operational order splitting.

For the Commerce Director, the central decision is not how many boxes each platform checks. It is determining which kind of complexity must be governed. A network may need to manage brands, languages, domains, and corporate structures—or it may need to ensure that customers find the correct part for their vehicle, route the sale to the appropriate regional dealership, and fulfill it from multiple sources without breaking the official customer experience.

The CFO looks at margin, fulfillment cost, and accountability for each order. The CTO needs to know where the catalog, regional rules, inventory, fulfillment, and order status live. A dealership marketplace is sustainable only when these decisions no longer depend on phone calls, spreadsheets, and individual memory.

The scenario: an official portal that turns the network into a coordinated operation

Imagine an automaker or distribution group bringing passenger-vehicle or commercial-vehicle dealerships together in an official storefront. The owner enters the vehicle information and expects to see only applicable parts. The dealership responsible for the customer’s region should appear first, while other dealerships and the manufacturer serve as backup sources when the preferred location cannot fulfill the order.

This model is not simply a marketplace with multiple sellers. It digitizes an operation that already has territories, contracts, inventory, technical expertise, and after-sales responsibilities. The marketplace is the visible result of a commercial policy that must remain valid even when the customer does not call the parts counter.

The architecture must also preserve context when the journey moves between channels. Customers may begin on their own, ask a sales representative for help, involve a technician, and continue with the same order. The sales-support agent must work from the current catalog, pricing, availability, and business rules—not produce an answer disconnected from the transaction.

The six decisions this scenario requires

The selection process begins with the operational decisions below. They serve as architectural and project-acceptance criteria, not as a generic feature list.

1. How customers find the part that fits their vehicle. Fitment must be treated as master data connected to vehicle identification and product references. Saving a customer’s garage reduces repeated data entry during the journey, but the decisive requirement is preventing a description- or part-number-based search from showing an incompatible part.

2. Which dealership serves the customer first. The regional offer must reflect the network’s commercial responsibilities, not merely rank sellers by advertised price. Territory, availability, lead time, and commercial terms must be considered before presenting the source that will serve the customer.

3. Where the product comes from when the regional dealership does not have it. A local stockout should not end the sale. The network’s policy must define which sources may take over an item, in what order, and under what conditions. The experience remains within the official portal instead of forcing customers to search elsewhere.

4. Who handles the chat. Assisted service must preserve the cart, the product being reviewed, the offered terms, and the conversation history. Sales representatives, technicians, and AI agents may perform different roles, but they must all operate from the same commercial context and record the next step.

5. How a multi-source order is split. When items come from different sources, the customer needs to see one coherent purchase while each responsible party receives its operational share. The architecture must connect the parent order to each dealership or manufacturer order and track invoicing, delivery, and status by source.

6. Who manages the fitment catalog. Quickly launching a storefront with raw data may simply transfer the parts-counter problem to the customer. The network must decide which fitments, attributes, images, and cross-references need to be governed before publication—and which process will continue enriching the catalog afterward.

What blocks the operation today, in the words of the people running it

Statements heard in the field show where operations break down and which architectural decision is hidden inside each complaint.

“I waste time looking for the right part; the fitment data is never complete.” This statement reveals the need to decide on the source of truth for fitment. If part numbers, naming, and compatibility do not form a governed structure, digital search merely presents the wrong part faster.

“The customer asks for a part, we don’t have it, and they buy from a competitor. My supplier has the item, but I have no way to sell it.” This exposes the decision around backup inventory sources. The network must turn dealerships and the manufacturer into coordinated commercial sources with explicit preferences, rather than treating every stockout as an exception handled over the phone.

“The customer calls with a machine down at a jobsite, provides the model and serial number, and the parts counter still has to determine which catalog item is correct and whether any branch has it.” The underlying decision is to combine technical identification and availability within the same journey. In commercial vehicles and heavy equipment, reducing downtime may matter more than a sophisticated editorial browsing experience.

Catalog management also produces measurable operational results. In a CWS customer operation during the 2024–2026 period, the time required to create a new SKU fell from 12 minutes to 45 seconds. In a CWS customer operation during the 2024–2026 period, 25,000 SKUs were created in 30 days.

What Adobe Commerce handles well in this scenario

The architecture organizes an instance into global, website, store, and store-view scopes. A website contains settings such as shipping and payment, while stores within the same website can share a catalog, administration, and checkout but use different products, menus, and designs, according to the website, store, and store-view documentation. This supports networks that model brands, countries, languages, or commercial experiences as digital destinations managed within the same structure.

For business buyers, a company account brings together users, divisions, roles, and permissions. Administrators can also enable payment methods, price levels, quote negotiation, requisition lists, and purchase orders subject to approval rules, according to the integrated B2B documentation. This mechanism is relevant when fleet operators, repair shops, or enterprise accounts purchase through the network with formal responsibilities assigned to requesters and approvers.

The merchandising layer can ingest catalog data from commerce platforms, PIM systems, or ERPs and organize it into sources, price books, views, and policies. Storefronts query this layer through APIs, while the cart and checkout remain in the connected transactional system, as described in the connector overview. The architectural emphasis is on separating product discovery from the transactional system of record.

Personalization can receive storefront events, order history, and profile data, sending them to the data network for segment and journey composition. The personalization documentation describes connections to ERP, CRM, and point-of-sale data for adapting campaigns, communications, promotions, and content. In a dealership scenario, this fits when the priority is coordinating content and customer relationships across channels using unified profiles.

How the CWS Platform assembles the operation: technical catalog, regional preference, and distributed execution in the same flow

The architecture begins with the Marketplace Management Platform (Marketplace Center), which represents dealerships and the manufacturer as participants in the operation, maintains the relationship between the parent order and child orders, and allows each source to update its portion. Product Catalog & MDM (Catalog Engine) governs products, SKUs, assemblies, inheritance, and incremental imports. Distributed Inventory (Inventory Hub) adds warehouse-level availability, inventory reserved for future offers, and lead time by SKU.

For the Commerce Director, the fitment catalog is not a cosmetic step. Make, model, year, trim, engine, and reference data must form verifiable relationships before they guide the storefront. The catalog-enrichment agent helps transform raw data, images, and attributes into structured content, while governance determines what can be published and what requires review.

This structure allows each warehouse to be treated as an operational context within the network. Service region, published catalog, inventory, commercial terms, and logistics can all participate in the central policy. Contextual Pricing (Pricing Engine) calculates the terms applicable to that context instead of assuming that price is an isolated value that remains identical across all sources.

When the regional dealership has the item, it receives the preference defined by the operation. When it cannot fulfill the request, other eligible sources enter the established sequence. Shipping & Fulfillment (Logistics Engine) calculates alternatives by source and supports split carts and partial deliveries, while the portal preserves a single customer journey.

The Assisted Selling Platform (Sales Hub) keeps the sales representative and buyer in the same cart, records the service interaction, and provides chat within the commercial operation. The sales-support agent uses the available context to assist with questions and next steps. Human intervention therefore does not require rebuilding the reviewed fitment, selected items, and negotiated terms in another channel.

After confirmation, the Order Management System (OMS / Seller Center) records the order as the operational reference shared by the platform, dealership, and ERP. Child orders remain connected to the parent order, and each source updates invoices, tracking information, and statuses according to its responsibilities. Rules can control state transitions, preventing an item from advancing without the data required for that stage.

Credit-First B2B Checkout (Checkout & Payments) incorporates credit into the B2B flow and validates inventory, price, credit, and taxes within the same transaction. If the commercial terms are rejected under the current rules, the order is not created. This matters when the same portal serves consumers, repair shops, fleet operators, and business buyers with different payment and authorization methods.

The CWS Platform has 11 modules, 6 AI Agents, and 1,029 configurable parameters. In a dealership network, this configuration expresses who may sell, which source has priority, which terms may be applied, and how the order proceeds through invoicing and delivery. The architecture places its emphasis on continuity between technical discovery, commercial decisions, and execution.

The appropriate benchmark is the supply chain’s transaction cost. Finding the correct fitment, checking multiple sources, bringing in someone to help, splitting execution, and tracking each delivery all consume labor—even when the order is digital. The official portal creates value when it reduces these handoffs without taking away the network’s control over territory, price, availability, and accountability.

Where the architectures truly diverge

One architecture primarily expresses commercial separation through websites, stores, and store views, defining within that structure which scopes share catalog, cart, shipping, and payment capabilities, according to the multiple websites structure. The other uses participants, warehouses, regional rules, and fulfillment sources to organize a distributed operation.

For discovery, one architecture can decouple merchandising from the system of record and publish catalog views queried by the storefront while keeping the cart and checkout in another connected system, according to the connector architecture. The other treats the technical catalog, availability, and sourcing policy as continuous parts of the commercial decision.

For B2B service, one architecture places the emphasis on the buying account structure, including its users, roles, quotes, and purchase orders, as detailed in the integrated B2B solution. The other concentrates the context in the shared cart, commercial rules, source-level inventory, and order execution among network participants.

Adobe's own documentation records two limits of the SaaS version:

• limitation recorded in the vendor's documentation on October 8, 2026: Adobe Commerce as a Cloud Service does not support Luma storefronts ("does not support Luma storefronts", https://experienceleague.adobe.com/en/docs/commerce/cloud-service/overview).
• limitation recorded in the vendor's documentation on September 24, 2026: the data migration service covers only first-party core commerce data, not custom or third-party entities ("supports first-party core commerce data only", https://experienceleague.adobe.com/en/docs/commerce/cloud-service/migration/overview).

The table does not identify an abstract winner. It shows where each design requires the company to model its complexity. The selection should follow the real unit of governance: digital destinations and corporate structures, or the physical network, inventory sources, technical fitment, and operational responsibility.

When Adobe Commerce is the right choice for this scenario

In some situations, the dealership network’s core requirement clearly points to this architecture. In those cases, the fit comes from how it structures the problem—not from a generic feature-inventory comparison.

The network needs to manage brands, countries, and languages as distinct digital destinations. Choose this architecture when websites, stores, and store views are the primary units of organization, with catalog, cart, shipping, and payment capabilities shared or separated by scope. The documented mechanism defines a hierarchy for this administration and for publishing each destination, according to the website and store documentation.

Fleet operators and enterprise accounts require a formal buyer structure. Choose this architecture when purchasing must reflect companies with divisions, users, roles, permissions, quotes, and purchase orders subject to approval rules. The company account and its controls are defined components of the integrated B2B solution.

The project separates merchandising from the transactional system. Choose this architecture when the requirement is to ingest data from a PIM, ERP, or commerce platform, normalize it into catalog sources and views, and provide it to the storefront through APIs while keeping the cart and checkout in the connected system. This design is described in the merchandising layer overview.

The priority is personalizing content and journeys with data from multiple channels. Choose this architecture when storefront events, order history, profile data, CRM, ERP, and point-of-sale information must feed segments, campaigns, and omnichannel communications. The data flow and its connection to profile and journey services appear in the personalization documentation.

Where to go next

If your question is still which architecture fits your operation—not which vendor to choose—the next step is the seven questions that distinguish B2B commerce architectures.

If the current obstacle is the pain behind this scenario, When the Catalog Turns Into Chaos examines it in depth without discussing any vendor.