Salesforce Commerce Cloud Deep Dive
Architecture, Unified Commerce and Agentforce Under Scrutiny
Andreas RiegerSalesforce Commerce Cloud is an established enterprise commerce offering for organisations managing complex trading operations, international business models and extensive requirements for connecting commerce with customer relationships and service.
It is often viewed as part of a broader, integrated Salesforce environment. There are good reasons for this. Salesforce offers an extensive portfolio spanning digital commerce, physical retail, order management, customer data and, increasingly, AI-driven business processes.
The underlying architecture, however, is more varied than the common product branding might suggest.
B2C Commerce and B2B Commerce emerged from different technological foundations. Products for order management, point of sale, payments and data integration extend the portfolio. Agentforce adds another layer, allowing AI agents to interpret information, support operational activities and initiate certain business processes.
These developments expand what Salesforce Commerce Cloud can potentially deliver. They do not automatically change the architecture of the systems underneath.
The relevant question is therefore not how many Salesforce products can be connected. It is which business processes can operate reliably across those products, what is required to make that possible and which technical and commercial dependencies follow.
This Deep Dive examines Salesforce Commerce Cloud from that perspective. It distinguishes vendor positioning from documented product capabilities and independent analysis. There are no numerical ratings and no general platform recommendation.
1. Executive Summary: One Portfolio, Several Technical Realities
Salesforce Commerce Cloud is better understood as a portfolio of commerce applications and supporting platform services than as a single, uniform commerce system.
Its B2C offering is based on the former Demandware technology, with a dedicated commerce engine, an established SaaS operating model and several approaches to storefront development.
B2B Commerce has a different history. Originating from CloudCraze, it is more closely associated with the Salesforce data model and the capabilities of the Salesforce Platform.
These differences remain relevant even as Salesforce markets both product lines under one umbrella and develops shared services across the portfolio.
For businesses already using Salesforce, connecting commerce with customer information, sales and service can offer meaningful advantages. It may simplify access to customer context and provide new opportunities to coordinate processes across channels.
Yet products supplied by the same vendor do not automatically integrate without friction. Data models, permissions, system ownership and business processes still need to be aligned, including within Salesforce's own portfolio.
This becomes particularly apparent in Unified Commerce.
Salesforce now offers its own products for point of sale, order management and inventory processes. These provide important components for a connected retail architecture.
Whether a retailer actually achieves consistent inventory, shared customer identities and coordinated order and returns processes depends on the implementation.
A consolidated customer profile is not the same as a unified inventory model. An integrated order management product does not, by itself, guarantee consistent fulfilment and returns.
Agentforce introduces an additional dimension.
Salesforce now offers generally available agent products for shopping, B2B purchasing and merchandising. It is also developing integrations with external AI systems and open commerce protocols.
Their technical maturity varies considerably.
Some capabilities are available for production use. Others remain in pilot or carry restrictions relating to language, region, edition or distribution channel.
The distinction between AI-assisted product advice and an executed transaction is particularly important.
An agent capable of recommending products or preparing a basket is not necessarily authorised or technically equipped to complete payment, manage an order, cancel a purchase or process a refund.
For executives and commerce leaders, the implication is straightforward.
Salesforce Commerce Cloud should be assessed by the business processes an organisation can operate reliably and economically, rather than by the breadth of the Salesforce portfolio.
This applies equally to new platform decisions and to the development of an existing Salesforce environment.
2. Salesforce Commerce Cloud and the Question of Product Identity
A changing name, different technical foundations
Salesforce did not make its product terminology particularly easy to follow in 2026.
In June, the company introduced Agentforce Commerce as the new name for its commerce offering. The change was intended to reflect a strategic shift towards AI-assisted and agent-driven commerce.
A few months later, Salesforce returned to the familiar Commerce Cloud name. Its current product page explicitly describes Commerce Cloud as formerly Agentforce Commerce.
This Deep Dive therefore uses the current name, Salesforce Commerce Cloud.
Agentforce refers to Salesforce's AI agent platform and the capabilities built upon it.
A change of name is not, in itself, a technical event. Nevertheless, this episode illustrates a recurring challenge in evaluating enterprise software. Common branding tells us relatively little about how the underlying products are actually constructed.
Source: Salesforce Commerce Cloud, official product overview.
The historical separation of B2C and B2B
Salesforce acquired Demandware in 2016 and CloudCraze in 2018.
These acquisitions led to two commerce product lines which continue to have different technical foundations.
B2C Commerce uses the Demandware-derived commerce architecture, with its own runtime environment, Business Manager, storefront technologies and Commerce APIs.
B2B Commerce is built around the Salesforce Platform, making greater use of its data structures, business accounts, permissions and application capabilities.
The distinction extends beyond how individual features are developed. It affects integration, data management, extensibility, operations and organisational responsibilities.
A business seeking to bring B2C and B2B operations together cannot assume that both models use the same transactional data structures simply because they belong to the same product family.
At the same time, Salesforce increasingly presents its commerce portfolio as an integrated suite supported by common services and a shared data foundation.
That proposition should not be dismissed merely because the products have different histories. Shared services, connected data and coordinated business processes can be established across technically distinct applications.
The important distinction is where data is genuinely managed in common, where synchronisation is required and where separate applications continue to enforce their own business rules and execute their own transactions.
Source: Salesforce Processor Binding Corporate Rules, product documentation.
The wider commerce portfolio
Salesforce provides several additional applications beyond its core B2C and B2B offerings.
Salesforce Order Management supports order processing and orchestration. Omnichannel Inventory addresses inventory availability and related processes. Salesforce Payments provides payment capabilities, while Salesforce Point of Sale connects physical retail operations with other Salesforce applications.
Sales Cloud, Service Cloud, Marketing Cloud, Data 360 and integration services such as MuleSoft extend the possible architecture further.
Together, these products can support a substantial commerce environment.
They are not, however, all components of a single commerce engine. Their technical relationships and commercial prerequisites have to be assessed individually.
The breadth of the portfolio creates opportunities for integration. It also creates the conditions for considerable complexity.
3. The Architecture: Two Commerce Worlds Within One Ecosystem
B2C Commerce and the Demandware engine
Salesforce B2C Commerce operates as a multi-tenant SaaS solution.
Salesforce manages the underlying infrastructure. Merchants focus on configuration, development, integration and the operation of their commerce applications.
The core provides capabilities for products, categories, price books, promotions, customer accounts, baskets and orders.
Business Manager remains the central administration environment for many of these functions.
The operating model has a clear advantage. Organisations do not need to build and maintain their own underlying commerce infrastructure.
Technical freedom is nevertheless bounded by the available extension mechanisms, runtime conditions and supported interfaces.
Businesses developing extensive custom logic must implement it within the Salesforce operating model and maintain it through the relevant release cycles.
Storefront Reference Architecture
Salesforce's Storefront Reference Architecture, or SFRA, provides an established approach to server-rendered B2C storefronts.
It uses a JavaScript-based controller model, with extensions implemented through mechanisms including cartridges.
SFRA provides a structured starting point for conventional storefront implementations.
Its long-term maintainability depends heavily on the degree of customisation.
A storefront with limited modifications presents a different operating challenge from an implementation that has accumulated extensive custom cartridges, controllers and integrations over several years.
The cost of future change therefore depends less on the decision to use SFRA itself than on the architecture of the extensions built around it.
Composable Storefront and Storefront Next
For decoupled frontends, Salesforce offers Composable Storefront, using PWA Kit and Managed Runtime.
The frontend is developed using React and connects to backend capabilities through Commerce APIs.
This provides greater freedom in user-interface development and the integration of external components.
Decoupling the frontend does not, however, turn the underlying commerce engine into a collection of independently replaceable services.
Composable Storefront is primarily an alternative presentation and integration architecture within Salesforce B2C Commerce.
Salesforce is also developing Storefront Next as a newer storefront approach.
Here it is important to distinguish the target architecture from the tools intended to support migration towards it.
Salesforce also provides an AI-assisted migration accelerator for Storefront Next. As of 28 October 2026, this migration tool remains in Developer Preview and is not intended for production use. This status should not be confused with the availability of the Storefront Next architecture itself.
The tool can assist with the analysis and partial transformation of existing storefront structures. It does not remove the need to migrate or review custom business logic.
Custom controllers, payment integrations, localisation, specialised frontend features, security testing and performance optimisation remain separate responsibilities.
For existing merchants, the decision therefore extends beyond the frontend.
The question is not simply which storefront technology appears more modern. It is which existing capabilities, extensions and process dependencies can be retained or adapted at an economically reasonable cost.
The transition from OCAPI to SCAPI
One of the most tangible architectural developments concerns Salesforce's API landscape.
Salesforce officially deprecated the Open Commerce API, or OCAPI, in April 2026.
Salesforce Commerce API, or SCAPI, is now the recommended approach for new implementations. Since 1 September 2026, OCAPI settings have generally no longer been available by default for newly provisioned customer realms. Existing customers may request continued access under certain conditions.
Salesforce continues to document support and security maintenance for OCAPI, without specifying a final shutdown date. If formal end-of-life is announced, Salesforce's policy provides for at least two years' notice.
The transition involves more than replacing API endpoints.
SCAPI introduces different authentication and integration mechanisms, particularly through Shopper Login and API Access Service, or SLAS. Salesforce also documents architectural differences relating to API behaviour and caching.
An existing OCAPI integration cannot therefore always be modernised simply by changing endpoint addresses.
Organisations need to identify where OCAPI is used, which custom functions are affected, how authentication and session management operate and which business rules depend on existing hooks or extensions.
Under certain conditions, SLAS can also support a phased transition.
The commercial implication is neither that existing integrations have suddenly become unusable nor that a platform replacement is necessary.
It is a definable migration requirement which needs to be planned and funded.
Sources: Salesforce OCAPI Deprecation Policy, OCAPI Settings and Why Use SCAPI.
B2B Commerce and the Salesforce Platform
B2B Commerce follows a different product logic.
Business accounts, contacts, account relationships and purchasing permissions are more central than in a conventional anonymous consumer checkout.
The architecture uses Salesforce-oriented data structures and supports closer connections with sales and service processes.
This can be particularly relevant where customer relationships are already managed within Salesforce.
That proximity does not mean, however, that the business rules of Sales Cloud, Revenue Management and B2B Commerce automatically align.
Contract pricing, quotations, credit limits, budgets and purchasing approvals all require clear decisions about which system holds the authoritative rules and where those rules are enforced.
Architecturally, Salesforce Commerce Cloud remains a portfolio of products with different strengths and operating models. A connected Salesforce environment can integrate those differences. It does not make them disappear.
4. Commerce Capabilities and Operational Reality
B2C: Extensive trading capabilities within defined boundaries
Salesforce B2C Commerce covers a broad range of digital commerce requirements.
These include product catalogues with variants, price books, promotions, content capabilities, search, merchandising, customer accounts, baskets and order processing.
Multi-site functionality supports different brands, countries and storefronts. Prices, languages and assortments can be managed for different markets.
For international trading organisations, this allows several commercial contexts to operate within one commerce environment.
Multi-site support should not, however, be confused with a complete international operating model.
Local taxation, payment methods, regulatory requirements, delivery processes and organisational responsibilities still need to be addressed.
Product information management also requires a distinction.
B2C Commerce includes catalogue and product data capabilities required for selling. Businesses managing extensive supplier information, complex attribute models or cross-channel product enrichment may nevertheless benefit from, or require, a separate PIM.
This is not necessarily a weakness in the commerce product.
It is a question of system responsibility.
The commerce catalogue must provide information suitable for selling products. It need not be the authoritative system for every aspect of product information across the business.
Search, merchandising and personalisation
Salesforce offers established capabilities for product search, placement, promotions and personalised shopping experiences.
Einstein capabilities and newer AI-supported search approaches extend these possibilities.
Search quality, however, is not determined by technology alone.
Product information, categorisation, customer terminology, synonyms, availability and commercial rules all influence whether customers receive relevant results.
AI-supported search cannot be expected to compensate indefinitely for poor product data.
For management, the distinction is between the availability of a technology and its operational performance.
A new search capability may extend what a team can achieve. Its commercial impact still needs to be demonstrated against the realities of the assortment and customer behaviour.
B2B Commerce: When the customer is an organisation
B2B purchasing changes the underlying structure of a commerce transaction.
The customer is often not an individual but a business with several locations, departments and purchasing roles.
Different people may have different permissions, budgets, product entitlements and responsibilities.
Salesforce uses structures including Accounts, Buyer Groups, Entitlement Policies and Price Books to manage these relationships.
These mechanisms help determine which products buyers can access and which prices apply.
Buyer Groups can support customer-specific assortments and pricing arrangements.
Entitlement Policies can restrict access to particular products, while Price Books establish the relevant prices.
B2B Commerce therefore provides concrete mechanisms for handling differentiated purchasing conditions.
The relationships between accounts, buyer groups and pricing rules still need to be designed deliberately. Complex organisational hierarchies do not emerge automatically from the use of a shared CRM data model.
Source: Salesforce: Buyer Groups, Entitlements and Pricing Strategies.
Contract pricing and quotation processes
Pricing is frequently one of the defining architectural questions in complex B2B operations.
A manufacturer may agree individual commercial terms with a customer based on volume, product categories, contract duration or framework agreements.
B2B Commerce can represent customer-specific prices and product entitlements.
More demanding quotation and negotiation processes may involve additional Salesforce applications and business rules.
Salesforce documents, for example, a Request for Quote process in which buyers can generate a quotation request from their basket.
Sales representatives can review prices, quantities and terms. Customers may then accept the quotation or continue negotiations.
Depending on configuration, these activities involve Sales Cloud or Agentforce Revenue Management.
An approved quotation can subsequently be incorporated into the purchasing process.
This illustrates an important architectural point.
The commerce storefront is not necessarily the authoritative system for every pricing and contractual decision.
Source: Salesforce: Request for Quote.
Purchasing approvals, budgets and procurement rules
Authorisation provides another important distinction from consumer commerce.
An employee may be permitted to select products without being authorised to place a binding order.
A purchasing department may impose spending limits. Orders above a particular value may require additional approval.
Not every such rule is necessarily available as a fully integrated standard process in every B2B Commerce edition.
Salesforce Flow, Revenue Management or external procurement systems may be involved.
From an architectural perspective, three areas of responsibility need to be separated.
The storefront determines which products a buyer may see and select.
The purchasing organisation determines who may approve or submit an order.
The ERP or authoritative order system may then decide whether credit limits, availability, contractual terms and other conditions permit the order to be accepted.
These responsibilities may overlap. They must not conflict.
A typical B2B procurement journey
Consider a business customer signing in to its purchasing portal.
The commerce application identifies the relevant business account and establishes which products and prices apply.
The buyer assembles an order.
Some products are covered by pre-agreed prices. Others require a quotation.
The responsible sales team processes the request, and the approved terms are made available for purchasing.
Before the order becomes binding, the system must establish whether the buyer has the necessary authority and whether additional internal approval is required.
ERP, inventory and order management applications may subsequently perform further checks and process the order.
The quality of this architecture depends on how reliably these steps operate together.
A functional product catalogue and a successful checkout are not sufficient evidence of a complete B2B procurement architecture.
Recurring procurement
Reordering, purchasing lists and quick-order capabilities are particularly important in B2B.
Salesforce supports corresponding purchasing scenarios.
A recurring purchase, however, is not automatically the same as an authorised standing order or continuing contractual commitment.
Automated procurement still needs to accommodate price changes, availability, delivery conditions and purchasing limits.
Agentforce makes this distinction more important, as AI agents may increasingly prepare or initiate repeat orders.
In B2B commerce, the reliable enforcement of commercial agreements and purchasing rules can matter more to project success than the range of visible storefront features.
5. Unified Commerce: When Integration Becomes the Real Platform
Salesforce positions Commerce Cloud as part of a unified commerce environment.
With products for commerce, point of sale, order management, payments and data integration, the company offers many of the necessary components.
The portfolio is consequently broader than the traditional view of Commerce Cloud as an online shop platform.
The relevant question is how those components work together in live operations.
Customer identity and a consolidated customer view
Sales Cloud, Service Cloud and Data 360 can bring together information from different customer interactions.
The ability to make customer context accessible across channels is a meaningful capability within the Salesforce portfolio.
Data 360 can support the unification and use of information from different sources for analysis and applications.
A consolidated customer view is not, however, automatically the same as a shared transactional customer identity.
A registered B2C shopper, a B2B account, an in-store customer and a service contact may be subject to different identity and permission models.
Making these relationships operationally useful requires defined identity resolution, data quality, access rights and system responsibilities.
This is more than an integration task.
It is also a matter of data governance.
Inventory and order orchestration
Omnichannel Inventory and Salesforce Order Management extend commerce with capabilities for inventory availability and cross-channel order processing.
These functions can support processes such as Click & Collect, Ship-from-Store and allocation across different fulfilment locations.
Their presence in the Salesforce portfolio does not mean that every merchant automatically operates with one consistent inventory position.
ERP and merchandise management systems often remain involved.
Reservations, cancellations, split deliveries and inventory movements must also be processed consistently.
If an item appears available online but has already been sold in the store, the immediate problem concerns the accuracy and timing of operational data and processes.
The name of the commerce suite does not resolve it.
Salesforce Point of Sale
Salesforce expanded its physical retail capabilities through the acquisition of PredictSpring.
Its current point-of-sale offering addresses store transactions, customer interactions, inventory information and omnichannel processes.
The earlier assertion that Salesforce necessarily requires third-party solutions for point of sale is therefore no longer correct.
Yet POS integration must still be judged by what it can actually do.
Can an online purchase be returned in a store? Are promotions consistent across channels? Which system initiates and settles refunds? Are customer identities linked reliably? How are physical inventory movements recorded and communicated?
Only the answers to such questions establish whether multiple sales channels operate as one coherent commercial process.
An end-to-end retail journey as an architectural test
Consider a retailer operating an online shop and several physical stores.
A customer places an online order. The retailer intends to fulfil it from a nearby store.
A few days after delivery, the customer decides to return the item to a different branch.
From the customer's perspective, this should be a straightforward transaction.
Technically, it involves several distinct responsibilities.
First, the online storefront must identify the correct product variant and applicable selling price.
The system then checks available inventory.
It is not sufficient for a store simply to report positive stock. The item must be available for the intended fulfilment process and, where necessary, capable of being reserved.
Once the order has been placed, an order management system needs to determine which location should fulfil it.
The store's operational applications must receive the instruction and support the actual picking and despatch process.
When the item is sold or shipped, the relevant inventory movements need to be reflected consistently across the participating systems.
The subsequent return starts another process.
The receiving store must identify the original order and establish whether the return is permitted.
Inventory, order status and refund processing must then be updated correctly.
Depending on the payment method and contractual structure, different payment and financial systems may be involved.
Salesforce provides products and integration options for many of these activities.
The connections between Commerce, POS, Omnichannel Inventory, Order Management, ERP and Payments must nevertheless be configured or implemented accordingly.
This example is an analytical illustration, not a claim that every Salesforce Commerce installation supports the entire journey without additional configuration.
Its purpose is to demonstrate what an operationally connected commerce architecture must achieve.
Unified Commerce does not begin when all applications come from one vendor. It begins when data, business rules and operational responsibilities remain consistent throughout the transaction.
European operations and regional prerequisites
For organisations operating in Germany and the European Union, another consideration arises.
Not every Salesforce Commerce product, payment capability or Agentforce integration is available with identical functionality in every region.
International commerce architectures require checks covering supported countries, payment providers, currencies, data-processing conditions and local tax requirements.
Salesforce Point of Sale must also be assessed against the actual regional availability, contractual conditions and integration capabilities of the relevant product.
The public Salesforce pricing pages describe Retail Cloud Point of Sale as a separate offering. This does not establish that every intended country and feature combination is supported in production.
Salesforce Payments also has product-specific prerequisites. An international storefront does not, by itself, prove support for every local payment method.
From a data protection perspective, responsibilities between participating organisations, data flows, processing agreements and potentially international transfers all require consideration.
It would be insufficient to assume complete GDPR compliance simply because an organisation uses Salesforce cloud products.
Source: Salesforce Commerce Pricing & Editions.
The economics of Unified Commerce
Unified Commerce can improve customer experiences and reduce operational friction.
Achieving it may nevertheless require additional licences, integrations and the standardisation of existing business processes.
Not every retailer needs every component.
A business with a limited number of stores, a straightforward online operation and an effective existing ERP has different requirements from an international group operating multiple brands, warehouses and legal entities.
The strategic question is therefore not whether an entire Salesforce stack can be assembled.
It is which degree of integration creates demonstrable commercial value, and which systems are genuinely necessary to achieve it.
6. Agentic Commerce: From Product Advice to Transaction Execution
Agentforce has significantly expanded Salesforce's commerce strategy.
AI agents are intended not only to provide information but also to perform defined tasks within business processes.
These include internal merchant activities as well as interactions with consumers and business buyers.
By October 2026, the product landscape shows substantial progress. The distinction between announced capabilities, generally available products and complete operational processes remains essential.
Shopper Agent, Buyer Agent and Merchant Agent
Salesforce announced general availability for three commerce agents in the summer of 2026.
Shopper Agent is intended for B2C experiences, supporting conversational shopping and product discovery.
Buyer Agent addresses business purchasing scenarios, including interactions through messaging channels.
Merchant Agent is intended to support activities within the retailer's organisation, such as catalogue management, merchandising and the handling of certain operational information.
These products serve different purposes and require different permissions.
A Merchant Agent authorised to change product information needs different access rights from a Shopper Agent assisting a consumer.
A B2B agent preparing a repeat order must work within the commercial and procurement rules applying to that customer.
Nor does general availability of an agent product mean that every possible capability is supported in every edition, country or technical configuration.
For B2B Guided Shopping, Salesforce documents additional prerequisites, including relevant Commerce and Agentforce licences and the configuration of supporting data and AI services.
The practical availability of an agent must therefore be verified for the particular use case.
Source: Salesforce: Agentforce Commerce Release, July 2026.
External AI agents and open commerce protocols
Alongside Salesforce's own agents, another route to commerce is emerging.
External AI assistants can retrieve product information, support purchasing decisions and, subject to the relevant technical capabilities and authorisations, initiate transactions.
This changes the role of the merchant's storefront.
The storefront remains important, but it is no longer necessarily the only environment in which a purchase is researched, prepared or completed.
Interoperable interfaces and protocols therefore become increasingly significant.
Salesforce is pursuing several approaches with different levels of capability and maturity.
MCP: Access to tools is not an autonomous purchase
Salesforce documents a B2C Commerce MCP Shopper Service which allows external AI assistants to access selected commerce capabilities.
The documented tools include product discovery, product information and basket preparation.
The purchasing journey then leads the customer to the merchant's checkout through a link.
As of October 2026, MCP Shopper Service remains in pilot.
Salesforce also explicitly distinguishes it from Agentforce Shopper Agent. They are separate offerings.
The available toolset is limited and does not provide unrestricted access to the full range of SCAPI functions.
Authentication and access are controlled through defined technical permissions, including SLAS.
An external agent can therefore make use of commerce tools without independently completing payment or taking responsibility for subsequent order management.
MCP primarily addresses structured access to tools and information.
It does not, by itself, resolve the business authorisation of payments or the delegation of purchasing decisions.
UCP: A documented transactional integration, with restrictions
Salesforce has made more substantial progress with the Universal Commerce Protocol.
Its UCP integration is generally available from B2C Commerce release 26.9.
It supports the publication of a machine-readable business profile and the operation of protocol-based checkout sessions.
External platforms can use these commerce capabilities while the merchant remains the Merchant of Record.
The technical documentation also covers payment integration and the communication of subsequent order events.
This goes considerably further than distributing product information through feeds.
Important restrictions nevertheless apply in October 2026.
Salesforce currently documents UCP support for en-US sites. Google is identified as the first live platform partner, and merchants must complete a separate onboarding process.
The prerequisites include Business Manager configuration, a suitable payment provider, authentication through SLAS and product information prepared for the external channel.
Google additionally requires Merchant Center configuration, approval and end-to-end testing.
A generally available Salesforce implementation therefore does not mean that every European retailer can immediately sell in every language through every AI channel.
Sources: Salesforce UCP Integration Guide and Enabling Google as a Platform.
Checkout sessions and existing business logic
The technical documentation reveals an important integration requirement.
UCP checkout sessions use the underlying B2C Commerce basket and order capabilities.
Certain standard hooks continue to execute.
These include mechanisms supporting pricing, taxation, shipping calculations and basket validation.
Custom storefront controllers and certain resource-specific API extensions, however, do not execute automatically.
Business rules implemented exclusively in those components must therefore be reviewed and, where necessary, transferred to appropriate UCP or Commerce hooks.
This does not mean that UCP bypasses the existing commerce business logic as a whole.
It means that a production integration must account for the merchant's complete, actual checkout behaviour.
That may include minimum order values, delivery restrictions, custom price validations, address checks, compliance requirements or particular payment rules.
Post-purchase order processing also requires careful distinction.
Salesforce documents signed events for communicating changes in order status. This does not imply unrestricted access to all order management functions through UCP.
For example, release 26.9 does not document a general shopper order GET capability through UCP.
The integration therefore offers genuine transactional functions, but it should not be described as a universal order management interface.
Sources: UCP Configuration and Discovery and UCP Implementation Considerations.
ACP and other protocol approaches
Salesforce has also announced collaboration with OpenAI and Stripe around the Agentic Commerce Protocol.
This collaboration is strategically relevant.
It should not, however, be treated as equivalent to Salesforce's technically documented UCP implementation.
ACP-related integration approaches and product catalogue connections have been described. At the research date, sufficient evidence was not available to establish that all transactional capabilities had reached comparable general availability across Salesforce Commerce.
Similarly, the available evidence does not establish a specific, generally available Salesforce Commerce implementation of AP2 or WebMCP.
This does not mean such integrations are technically impossible.
It means they should not be treated as established standard capabilities when making an investment decision.
Agentic Commerce in Europe
Regional restrictions deserve particular attention.
A European merchant may be able to provide AI-assisted product search, guidance and basket preparation without having access to every capability of an external transactional protocol.
These scenarios must be assessed separately.
A product feed to an external AI channel can make products discoverable.
Conversational product advice can help customers decide what to buy.
Basket preparation can simplify the purchasing journey.
A complete transaction requires a supported checkout, valid pricing, taxes, delivery conditions and payment authorisation.
The documented en-US restriction of Salesforce's UCP integration must therefore neither be ignored nor presented as a restriction on the entire European Agentic Commerce market.
European retailers such as OTTO, Carrefour, Knuspr and dm may develop their own AI-assisted shopping experiences. Such initiatives do not establish Salesforce-specific capabilities unless the underlying implementation has been verified.
For a Salesforce Commerce Cloud assessment, the relevant evidence is the actual technical and regional availability of Salesforce's products.
From recommendation to purchase completion
A complete purchasing journey provides a useful way to assess Agentic Commerce.
Product discovery is only the beginning.
The system must subsequently resolve product variants, prices, availability and delivery conditions. The buyer or an appropriately authorised agent must be able to confirm or execute the transaction. Payment must be authorised and the order reliably created.
Further requirements arise after purchase.
Orders may need to be changed or cancelled. Deliveries may be delayed. Products are returned. Refunds must be processed.
A conversational interface alone does not meet these requirements.
The maturity of an Agentic Commerce architecture is demonstrated not by an agent's ability to recommend products, but by how reliably and controllably it participates in binding business processes.
Salesforce offers several relevant building blocks.
Which of them operate together in a particular scenario remains a matter of architecture and implementation.
7. Identity, Permissions and Control
Agent-driven purchasing changes the question of responsibility.
In a conventional checkout, the customer confirms the order within an environment controlled by the merchant.
With an external AI agent, product selection, basket preparation and parts of the transaction may take place outside that environment.
Several layers of identity and authorisation therefore need to be distinguished.
Buyer identity and technical authentication
The identity of the human buyer is not automatically the same as the technical identity of the agent.
An agent may use its own technical credentials, act on behalf of a customer or simply prepare information for a transaction that the customer later confirms.
Salesforce provides technical foundations for secure access to commerce functions through SLAS and other authentication mechanisms.
For UCP, Salesforce documents a dedicated technical scope for managing checkout sessions.
This makes it possible to control which application may call the relevant APIs.
Successful technical authentication does not, however, establish that an agent is authorised to perform every business action made technically possible by those credentials.
Delegated purchasing authority
An autonomous purchasing agent needs clearly defined boundaries.
These may cover products, quantities, total expenditure, delivery requirements, suppliers or recurring commitments.
Simply including such rules in a natural-language instruction to the agent is not sufficient.
What matters is where the rules are checked and enforced.
A spending limit contained only in an agent instruction provides a different level of assurance from a server-side validation immediately before an order is accepted or payment authorised.
The same applies to purchasing approvals, substitute products and amendments to orders already placed.
Delegated authority may also need to be revoked, depending on the business process.
Enforcing business rules within commerce
The commerce platform remains responsible for substantial parts of transactional business logic.
These include pricing, availability, delivery conditions and certain basket validations.
In an agent-driven checkout, those rules need to apply regardless of whether the customer purchases through the merchant's own storefront or an external channel.
Salesforce's UCP documentation demonstrates that existing Commerce hooks can be used for this purpose.
It also demonstrates that custom rules are not automatically executed at every new integration point.
The placement of business logic therefore becomes a governance decision.
A business-critical validation should not depend exclusively on a particular user interface.
Payment authorisation and delegated authority
Permission to retrieve product information or create a basket is not equivalent to permission to authorise payment.
A valid technical session does not prove that an agent may spend an unrestricted amount.
The respective responsibilities of the agent platform, commerce system, payment service provider and merchant must be defined.
At the research date, sufficient evidence was not available to establish a universally available Salesforce Commerce standard solution for complete autonomous purchasing mandates, including spending controls, revocation and recurring commitments.
Depending on the architecture, these requirements may involve additional components or custom rules.
Auditability and post-transaction control
Agent-driven processes must remain traceable.
Customer service teams need to understand what was ordered, which products were selected, what confirmation was given and which changes subsequently occurred.
Internal governance also requires visibility into permissions, technical actions and escalation events.
Privacy and data minimisation remain relevant.
Not every agent needs unrestricted access to complete customer profiles or historical transactions.
The objective is to provide each process with the information and authority it genuinely requires.
This produces a layered control model.
Technical authentication determines which system may access a service.
The business mandate establishes which decisions an agent may make.
Commerce applications enforce binding trading rules.
Payment processes establish financial authorisation.
The transaction and subsequent actions must then remain auditable.
Different applications may implement these controls.
They should not be mistaken for one another.
Agentic Commerce therefore extends not only the technical architecture of commerce, but also the responsibility for designing and controlling business decisions.
8. Operations, Extensibility and the Cost of Change
SaaS reduces infrastructure work, not integration responsibility
Salesforce Commerce Cloud operates as SaaS.
Salesforce is responsible for the underlying platform infrastructure, certain security measures and the delivery of core software capabilities.
This reduces the need for organisations to operate their own commerce infrastructure.
It does not transfer responsibility for the overall business architecture.
ERP, PIM, payments, customer service and other integrations still have to be designed and operated.
The same applies to custom extensions, data flows and business rules.
A broad Salesforce environment can consequently create substantial coordination requirements.
Release management and technical dependencies
B2C Commerce and applications built on the Salesforce Platform do not follow identical technical release and deployment processes in every respect.
Salesforce publishes product-specific versions, API changes and storefront developments for B2C Commerce.
The Salesforce Platform has its own release and deployment mechanisms.
Organisations combining these products must therefore manage several change cycles.
Custom extensions make this particularly relevant.
A change to a Commerce cartridge, an API integration and an extension of the Salesforce data model may require different testing and deployment procedures.
Modernising existing implementations
Older B2C Commerce environments face increasingly concrete modernisation decisions.
The transition from OCAPI to SCAPI is one example.
The choice between SFRA, Composable Storefront and Storefront Next may be another.
Technical modernisation should not, however, become an end in itself.
A new frontend technology does not automatically improve business processes.
Changing storefront architecture can make sense where existing constraints materially limit development or where the replacement offers demonstrable operational benefits.
It becomes more questionable where extensive custom functionality must be rebuilt without corresponding business value.
Integrations and MuleSoft
MuleSoft is an important element of Salesforce's integration portfolio.
It may have a valuable role in complex enterprise integration architectures.
Its use is not automatically required for every Salesforce Commerce implementation.
Existing middleware, direct APIs, integration platforms and specialised connectors may all be appropriate, depending on the circumstances.
The choice should follow requirements for data consistency, process orchestration, security, error handling and operational support.
Implementation partners and specialist knowledge
Salesforce has an extensive ecosystem of partners and systems integrators.
General Salesforce experience, however, is not necessarily equivalent to deep expertise in B2C Commerce.
SFRA, cartridges, SCAPI, Storefront Next and commerce-specific operating models require specialist knowledge.
The same applies to demanding B2B Commerce projects and cross-product integrations.
Access to the relevant capabilities should be considered early in project planning.
The economically important question is not simply whether an implementation partner is available.
It is how much technical and commercial knowledge the organisation must retain internally to operate, govern and change its commerce environment over time.
9. Economics: The Cost of the Entire Architecture
A licence is not a business model
Salesforce Commerce Cloud includes different products, editions and contractual models.
Public pricing information identifies separate offerings for B2C Commerce, B2B Commerce, Order Management, POS and Payments.
The included capabilities vary by edition.
Salesforce's current public pricing information describes extensive order management functionality within Commerce Cloud B2C Premium.
B2B Growth, by contrast, lists a basic order management capability, described as Order Management Lite.
Salesforce Order Management Growth is presented as a further offering with additional capabilities relating to distributed order management and omnichannel inventory.
These distinctions matter when evaluating a particular architecture.
They do not automatically establish what an existing customer is contractually entitled to use.
Salesforce's B2B documentation, for example, explicitly identifies licensing requirements for certain integrations with Order Management.
Published edition features must be checked against the customer's actual contractual entitlements, applicable product licences and the technical prerequisites of the intended integration.
Source: Salesforce Commerce Pricing & Editions.
An example of an economic architecture decision
Consider a B2B merchant wishing to offer customers better visibility into orders, delivery tracking and returns.
Some requirements may be covered by existing commerce or order management capabilities.
Others may require more extensive OMS functionality.
At the same time, the organisation already operates an ERP with its own order management processes.
Choosing an additional Salesforce product purely because it is available would be premature.
The first question is which system should remain authoritative for order information.
Only then can the business establish which additional capabilities Salesforce is expected to provide.
An extended Salesforce OMS may be justified if it closes material process gaps or simplifies existing integrations.
It may be less attractive if the relevant functions are already working reliably in ERP and another OMS primarily introduces further synchronisation requirements.
Equally, keeping all processes within the existing ERP may become expensive if numerous new channels and fulfilment models need to be connected.
The licensing decision cannot therefore be separated from the architectural decision.
Revenue-related and consumption-based components
Salesforce uses different commercial mechanisms across Commerce products and contracts, including revenue-related models.
The publicly available information does not provide a sufficiently reliable basis for applying standard percentage rates across all relevant editions and customers.
For this reason, the general GMV percentages and edition-specific figures included in the earlier version of this Deep Dive have not been retained.
Agentforce introduces further commercial mechanisms.
Salesforce publishes pricing models involving Flex Credits and conversations.
The cost of a particular commerce implementation nevertheless depends on the agent used, the actions performed, contractual arrangements and any supporting products.
A general Agentforce rate is not automatically the cost of a complete agent-driven commerce transaction.
Meaningful economic analysis requires modelling actual usage scenarios.
An agent answering product questions has a different cost structure from one which queries several systems, prepares orders, changes information and initiates subsequent processes.
The full cost picture
The total cost of a Salesforce Commerce environment has several layers.
Beyond platform licensing, organisations must account for implementation, integration, frontend development, custom extensions and operations.
Additional Salesforce products, external applications and integration services may be necessary.
Internal functions also incur costs.
Product data must be maintained, promotions administered, processes monitored and permissions governed.
As integration increases, architecture management and cross-functional governance often become more important.
Total Cost of Ownership is therefore more relevant than a comparison of isolated commerce licence fees.
Total Cost of Change
A second measure deserves equal consideration in long-term decisions.
Total Cost of Change concerns the effort and expense associated with adapting an architecture when business requirements evolve.
This may involve new sales channels, international markets, different fulfilment models, new business units or additional Agentic Commerce capabilities.
An architecture may be economical to operate today while becoming expensive whenever substantial changes are required.
Conversely, a more demanding initial integration may be justified if it provides a stable foundation for repeated future change.
The assessment must reflect the actual organisational context.
Understanding vendor lock-in
Salesforce uses proprietary commerce components and data models.
These can create switching costs.
The implications become particularly important when business rules, customer data, integrations and operational processes are closely connected across several Salesforce products.
Vendor lock-in should nevertheless not be treated as a single undifferentiated issue.
Technical dependency, data portability, contractual commitments and specialist organisational knowledge are separate factors.
A deeply integrated Salesforce environment may involve substantial switching costs while also delivering considerable commercial value.
The relevant decision is whether that value justifies the resulting dependencies.
The economic question is not whether Salesforce is expensive or inexpensive. It is which architecture the business actually needs, what measurable value it creates and how much freedom it retains to change direction later.
10. Decision Readiness: When Salesforce Commerce Cloud May Make Sense
Salesforce Commerce Cloud cannot usefully be assessed by company size alone.
An international retail organisation with complex customer relationships may have very different needs from a business with similar revenue but a straightforward direct-to-consumer model.
The existing technology environment also matters.
Existing Salesforce investments
Organisations already using Sales Cloud, Service Cloud or other Salesforce applications may possess technical and organisational capabilities that make the introduction of Commerce Cloud easier.
Existing expertise, data structures and integration patterns can potentially be reused.
An established Salesforce presence is not, however, sufficient justification for choosing its commerce products.
The question is whether the actual trading processes benefit from that proximity.
An existing CRM may improve access to customer context. It does not replace the need to evaluate catalogue, pricing, checkout and fulfilment requirements.
B2C, B2B and hybrid business models
For demanding B2C requirements, Salesforce provides an established commerce architecture with several storefront approaches and an extensive ecosystem of extensions and services.
For B2B, its connection to the Salesforce Platform may be particularly valuable where account relationships and sales processes are central to the commercial model.
Combined B2C and B2B operations require explicit consideration of the differences between the underlying product lines.
A shared CRM and common commerce branding do not automatically mean shared pricing, inventory, purchasing permissions or order processes.
Agentic Commerce as a decision factor
Agentforce and open commerce protocols are extending the strategic possibilities.
Businesses increasingly need to decide which information and transactions they wish to expose to external AI systems.
Salesforce offers relevant technical capabilities.
The current state of development does not, however, justify a general conclusion that every merchant needs a complete Salesforce stack to participate in Agentic Commerce.
Nor should an existing merchant automatically consider replacing its commerce platform because new agent capabilities have become available.
The first task is to establish which requirements can be met through existing Commerce APIs, supplementary services or targeted extensions.
Technological development creates a reason to investigate. It does not automatically create a reason to migrate.
When a more fundamental architectural review is warranted
A broader platform or architecture review may be appropriate where demonstrable structural limitations materially obstruct business requirements.
For example, custom business logic may demand disproportionate effort, integrations may remain persistently unreliable or a required business model may not be economically achievable through supported extension mechanisms.
Such constraints need to be established through evidence.
Dissatisfaction with particular features, expensive integrations or a new technology trend does not, by itself, demonstrate that an entire platform is unsuitable.
Before considering replacement, organisations should also examine targeted extensions, technical modernisation, process simplification and organisational improvements.
The questions management should be able to answer
Before introducing or substantially extending Salesforce Commerce Cloud, management should be clear about several matters.
Which systems hold the authoritative customer, product, pricing, inventory and order data?
Which business processes genuinely need to operate across B2C, B2B, physical stores and other channels?
Which Salesforce products are essential, which are optional and which existing systems can reasonably be retained?
Which Agentic Commerce capabilities are available in production in the required country, edition and channel?
Where are business rules, delegated purchasing authority and payment permissions technically enforced?
What recurring costs, integration dependencies and future change requirements will arise over several years?
And does the organisation possess the capabilities needed not merely to implement the architecture, but to govern it over time?
These questions provide a more useful basis for decision-making than a numerical platform score.
Management Conclusion
Salesforce Commerce Cloud offers an extensive technical and functional foundation for complex commerce environments.
It combines established B2C and B2B products with a broad portfolio covering customer data, order management, physical retail and AI-supported business processes.
Agentforce and open commerce protocols add new possibilities for making commerce functions accessible beyond conventional storefronts.
These developments matter. They should not, however, be mistaken for evidence that the entire commerce landscape has already become one technically unified platform.
The separation between the core commerce product lines remains relevant. Additional applications need to be integrated according to the business processes involved. Agentic Commerce capabilities differ in availability, transactional scope and governance.
None of this produces a universal argument for or against Salesforce Commerce Cloud.
The portfolio can provide a sustainable foundation for complex trading organisations where its capabilities, integration patterns and operating requirements align with the business.
It may become commercially or organisationally difficult to justify where the value of the resulting architecture does not warrant the effort required to integrate, operate and evolve it.
The quality of a commerce platform is not established by how convincingly its products are presented as one. It is established by how reliably an organisation can run and change its actual business processes through them.
Sources and Evidence Base
Research date: 28 October 2026
This analysis draws primarily on Salesforce product documentation, developer references, release information and published pricing and edition descriptions.
Statements about product positioning, functionality and availability are treated as vendor evidence. Conclusions concerning architecture, integration, economics and decision readiness are independent analytical assessments.
Product identity and portfolio
Salesforce: Commerce Cloud Product Overview
Current product terminology, portfolio and vendor positioning.
Salesforce: Commerce Cloud Pricing and Editions
Published product editions and their stated capabilities.
Salesforce: Processor Binding Corporate Rules
Product documentation and historical naming references.
B2C architecture and APIs
Salesforce Developers: Storefront Reference Architecture
SFRA architecture and extension model.
Salesforce Developers: Composable Storefront
PWA Kit and Commerce API integration.
Salesforce Developers: Why Use SCAPI
API strategy, architectural differences and migration guidance.
Salesforce Developers: OCAPI Deprecation Policy
Deprecation from April 2026 and applicable support policy.
Salesforce Developers: OCAPI Settings
Restrictions affecting new realms from September 2026.
B2B Commerce
Salesforce Help: Buyer Groups, Entitlements and Pricing
Customer-specific assortments, access rights and pricing strategies.
Salesforce Help: Request for Quote
Quotation processes and their connection with sales operations.
Salesforce Help: Order Management and Omnichannel Inventory
B2B integration and documented functional and licensing conditions.
Agentic Commerce and external protocols
Salesforce: Agentforce Commerce Release, July 2026
Vendor announcement concerning Shopper Agent, Buyer Agent and Merchant Agent.
Salesforce Developers: B2C Commerce MCP Shopper Service
Documented MCP capabilities and pilot status.
Salesforce Developers: Universal Commerce Protocol Integration
General availability, prerequisites, integration capabilities and restrictions.
Salesforce Developers: UCP Configuration and Discovery
Business profiles, protocol versions and configuration.
Salesforce Developers: UCP Implementation Considerations
Checkout hooks and custom business logic.
Salesforce Developers: Enabling Google as a Platform
Merchant Center requirements, approval and end-to-end testing.
Economics
Salesforce: Commerce Cloud Pricing and Editions
Published editions and commercial conditions.
Salesforce: Agentforce Pricing
Consumption-based pricing models; verify the current contract and regional applicability.
Glossary
Agentforce: Salesforce's platform and product family for developing and operating AI agents across business processes.
Agentic Commerce: Commerce processes in which AI agents retrieve information, prepare decisions or perform authorised actions, potentially including transactions.
ACP (Agentic Commerce Protocol): A protocol approach for structured integration of commerce functions into AI shopping environments, particularly associated with OpenAI and Stripe.
B2C Commerce: Salesforce's consumer commerce product line, originating from Demandware.
B2B Commerce: Salesforce's business commerce product line, with its historical foundations in CloudCraze.
Buyer Group: A grouping of business buyers used to manage product access and pricing in Salesforce B2B Commerce.
Composable Storefront: Salesforce's decoupled frontend approach based on PWA Kit and Managed Runtime.
Data 360: Salesforce's data platform for connecting and using information across sources, formerly known as Data Cloud.
Entitlement Policy: A set of rules controlling access to and visibility of products for particular buyer groups.
MCP (Model Context Protocol): A protocol for structured access to tools and information by AI applications.
OCAPI (Open Commerce API): Salesforce B2C Commerce's older API family, deprecated since April 2026.
SCAPI (Salesforce Commerce API): Salesforce's recommended API family for new B2C Commerce implementations.
SFRA (Storefront Reference Architecture): A Salesforce reference architecture for server-rendered B2C storefronts using controllers and cartridges.
SLAS (Shopper Login and API Access Service): Salesforce's service for authentication and authorised access to Commerce APIs.
UCP (Universal Commerce Protocol): An open protocol approach supporting interoperable communication between commerce platforms and external applications or AI agents.
Unified Commerce: The organisational and technical coordination of sales channels, customer information, inventory, orders and service processes.
WebMCP: An approach to exposing website functionality as structured tools for AI agents. A generally available Salesforce Commerce implementation was not sufficiently evidenced at the research date.
About the Author
Andreas Rieger is an independent e-commerce and AI consultant with more than 20 years of experience in digital commerce. He advises organisations on platform decisions, commerce architectures and the organisational integration of digital business processes.
His assessments are vendor-independent, with no preferred implementation platform.