Salesforce for Retail & Ecommerce: What to Build in 2026

Key Takeaways: 

• Salesforce Order Management already handles orders, returns, refunds, fulfilment and change orders, so rebuilding the core order model is usually unnecessary.
• B2C Commerce is separate from the Salesforce core, while B2B and D2C Commerce are native, making B2C integration a distinct development workstream.
• Custom development is most valuable for clienteling apps, returns portals, complex promotions, POS and inventory integrations, marketplace workflows, and regional tax logic.
• Salesforce Loyalty Management already provides standard loyalty objects, so building a custom points engine is generally unnecessary.
• Retailers using Shopify or Magento can still use Salesforce Order Management behind the existing storefront instead of replacing it.
• POS and inventory integration can become the hardest technical challenge, particularly when the source system cannot provide truly real-time availability.
• Keeping cardholder data outside Salesforce and using payment-gateway tokenization helps limit PCI DSS scope.
• Retail projects need to account for peak trading freezes, which can compress delivery timelines significantly.

Quick Answer: Retailers should use Salesforce’s standard Order Management, Commerce and Loyalty capabilities as the foundation, then custom-build only where their workflows genuinely differ. The strongest development opportunities are clienteling, returns portals, complex pricing and promotions, POS and inventory integration, marketplace workflows and regional compliance. The key architectural decisions are understanding the B2C Commerce platform boundary, respecting the immutable Order model and designing inventory experiences around the latency the source system can actually support.

Two things determine whether a retail Salesforce project goes well, and both get decided before anyone writes code

The first: Salesforce Order Management already ships one of the most complete data models on the platform – Order, Change Order, Order Summary, Fulfilment Order, returns, refunds and reshipments, all wired together. Rebuilding it is the expensive mistake in this sector.

The second and less well-known: B2C Commerce doesn’t run on the Salesforce platform. It sits outside the core and connects through a Heroku application. B2B and D2C Commerce are native. That single fact changes every integration decision you’ll make.

Where Standard Salesforce Stops for Retail

Sales Cloud assumes a salesperson working a pipeline. Retail assumes something structurally different: high-volume transactions with no salesperson involved, orders that change repeatedly after they’re placed, inventory that exists somewhere else, and a customer whose identity is fragmented across web, store, app, and marketplace.

Order Management and Commerce Cloud close most of that gap – a complete order lifecycle, fulfilment routing, returns handling, and storefronts for B2B, D2C, and B2C.

What they don’t close is your store operations, your promotion rules, your POS estate and whatever inventory system actually knows what’s on the shelf. That’s where development starts.

Don’t Rebuild What Order Management Gives You

Three-column comparison showing what is already standard in Salesforce Order Management, what should be extended and what genuinely needs custom building

Loyalty Management is standard too – Loyalty Program, Member, Tier, Ledger, Promotion. Building a custom points engine is a recurring and expensive error in this sector.

Product, Price Book, Promotion, and Store data all have standard homes. Almost everything a retailer lists as “we’ll need a custom object for…” exists somewhere.

The honest exception: genuinely unusual commercial models – marketplace and dropship with complex settlement, subscription-plus-physical hybrids or franchise structures with separate legal entities. Those are architect conversations.

Those unusual commercial models are ultimately an architecture decision. Understanding the difference between a Salesforce admin, developer, and architect helps determine whether the requirement can be configured or needs custom engineering and architectural design.

Related: the Salesforce data model explained · configuration vs customization

The Order Lifecycle: Never Modify the Order

Diagram showing Order flowing to Order Summary, Fulfilment Order and Change Order, with the rule that Orders are immutable after activation

This is the design pattern that trips up developers arriving from other commerce platforms.

In most systems, an order record gets updated as things change. In Salesforce Order Management, it doesn’t. The Order captures customer intent and becomes immutable once activated. Every subsequent change – cancellation, return, refund, reshipment, discount adjustment – creates a Change Order. The Order Summary is the hub that aggregates everything into a single current-state view.

Why it’s designed that way: you get an immutable audit trail of what was ordered and everything that happened afterwards, which matters for finance reconciliation and dispute handling.

Why it causes problems: a developer who writes directly to the Order object breaks the model, and the symptoms appear later as reconciliation failures rather than immediate errors.

Two flows do the heavy lifting – Create Order Summary generates summaries from the original order and Create Fulfilment Order kicks off the shipping process and pushes to your WMS. Understand both before customising anything in the order lifecycle.

B2C Commerce Isn’t On the Salesforce Platform

Comparison showing B2C Commerce as a separate platform connected via Heroku versus B2B and D2C Commerce running natively on the Salesforce core

B2C Commerce lives outside the Salesforce core. It’s connected by an out-of-the-box Heroku application that brings orders into Salesforce. It has its own data model, its own admin, and its own development model.

B2B and D2C Commerce are native. They share the management app, components, commerce services and data model with the rest of the platform. Orders are created directly in Salesforce.

What this means practically:

• B2C integration is a genuine workstream, not configuration. Anyone quoting it as a connector switch-on hasn’t built one.
• Customer identity resolution across B2C and CRM is a real design problem – see Data 360.
• The skill sets differ. B2C Commerce development (SFRA, PWA Kit, now Storefront Next) is a different discipline from Apex and LWC. A generalist Salesforce developer is not automatically a B2C Commerce developer.

Also worth knowing: Storefront Next is now the recommended storefront for Commerce Cloud, replacing the older SFRA and PWA Kit approaches for new builds. If a partner is scoping SFRA for a greenfield storefront, ask why.

Related: Salesforce integration guide

Commerce Cloud or Build on Core?

Where core Salesforce alone is genuinely fine: a retailer whose ecommerce runs on Shopify or Magento and who wants Salesforce for service and marketing only. That’s a common and sensible architecture – Order Management can sit behind a non-Salesforce storefront, which is a point most Salesforce-partner content avoids making.

Where it isn’t: anything needing a unified view across channels or complex post-purchase handling. Custom-building an order lifecycle is a multi-year commitment most retailers underestimate.

For standard retail workflows, a configuration-first approach is usually more economical. Salesforce low-code development can handle much of this work while custom engineering is reserved for requirements that genuinely fall outside the platform’s standard capabilities.

Related: Salesforce customization cost

What Retailers Actually Build

This is where Salesforce Development Services become valuable, extending Salesforce with the store experiences, promotion logic, returns workflows, POS and inventory integrations, and regional requirements that are specific to each retailer.

• Store Associate and Clienteling Apps: Mobile tools for shop-floor staff – customer lookup, product availability, endless aisle ordering, appointment booking. Almost always custom, because store operations differ enormously.
• Returns and exchange portals: Standard returns handling exists; the customer-facing experience around it usually doesn’t match what a brand wants. More complex, multi-stage processes can use Salesforce Flow Orchestration to coordinate steps across teams and systems.
• Promotion And Pricing Logic: Standard promotions cover common cases. Complex stacking rules, personalised offers and market-specific pricing usually need custom logic.
• POS And Inventory Middleware: The integration that makes “is it in stock in the Manchester store?” answerable. Consistently the hardest technical problem in retail Salesforce.
• Marketplace And Dropship Handling: Multi-vendor fulfilment, settlement and returns across parties that aren’t you.
• Regional Tax And Compliance Logic: Particularly for retailers selling across jurisdictions with different VAT, GST and consumer-rights regimes.

The Integration Surface

Two Things Worth Calling Out:

• PCI DSS Scope: The cheapest way to stay compliant is to keep cardholder data out of Salesforce entirely – tokenise at the gateway and store only the token. Teams that store card data “temporarily” for a business reason expand their audit scope substantially.
• Real-Time Inventory. Almost every retail Salesforce project promises accurate cross-channel availability, and almost every one discovers the inventory system can’t provide it at the required latency. Establish what’s actually possible before designing the customer experience around it.

Related: Salesforce API integration · Salesforce compliance and data security

What It Costs

Indicative bands, excluding licences:

Peak Trading Changes The Shape Of A Retail Project: Most retailers have a code freeze from roughly October to January, which compresses the delivery year and makes September deadlines immovable in a way other industries don’t experience. Plan the roadmap around it rather than discovering it in month three.

The Mistakes That Cost Most

• • Rebuilding the order data model. The expensive one.
  • Writing directly to the Order object. Breaks the Change Order model and surfaces later as reconciliation failures.
  • Treating B2C Commerce integration as configuration. It crosses a platform boundary.

• Promising real-time inventory the source system can’t deliver.

• • Storing card data in Salesforce. Expands PCI scope for no good reason.
  • Building a custom loyalty points engine. Loyalty Management exists.

• Ignoring peak trading freeze in the delivery plan.

Where to Go Next

For the integration surface, Salesforce integration and Salesforce API integration.

For unifying customer identity across channels, Data 360.

For the build decision, configuration vs customization and custom Salesforce development.

For budgeting, Salesforce customization cost.

For PCI and privacy obligations, Salesforce compliance and data security.

The complete Salesforce development guide is the hub.

Before You Scope a Retail Build

Three questions change the shape of most retail Salesforce projects.

What’s already standard in Order Management

Usually more than the scope assumes.

Is your storefront on the Salesforce platform or not?

B2C Commerce crosses a boundary; B2B and D2C don’t.

What latency can your inventory system actually deliver?

It determines what the customer experience can honestly promise.

Getting the third one wrong produces the characteristic retail failure: a beautifully built experience showing stock levels nobody trusts.

We’re a certified Salesforce Consulting Partner with developers, architects, and consultants across the US, UK, Australia, Canada, UAE, and India.

With POS, inventory, storefront, and ERP dependencies affecting delivery, an Agile methodology in Salesforce can help break the implementation into controlled releases while working backward from peak-trading freeze dates.