Salesforce B2C Commerce is the platform formerly known as Demandware. It runs production storefronts for thousands of retail, fashion, and B2C brands. The platform is mature, opinionated, and rewards teams that work with its conventions rather than against them.
This guide is the production reference Sapota's Salesforce team uses on B2C Commerce engagements. Each phase links to a deep-dive post on the topic. Read the pillar for the shape; read the deep posts for the patterns.
Phase 1: Foundation and architecture
The first decisions on any B2C Commerce engagement shape everything downstream. Two questions matter most:
SFRA vs SiteGenesis. For new sites, SFRA. For existing SG sites, evaluate the cost-benefit of migration. See SFRA vs SiteGenesis: when migration is worth the cost.
Cartridge path composition. The cartridge path is the most consequential configuration in any B2C Commerce site. Get the order right and customizations compose cleanly. See The B2C Commerce cartridge path: how modules actually compose.
For multi-site realms, additional decisions: master catalog scope, storefront catalog organization, inventory list assignment, customer list strategy, library sharing. See B2C Commerce multi-site architecture: catalog and inventory sharing.
Phase 2: Storefront UI
The customer-facing layer is where most engineering hours land. Three areas matter:
ISML templates. The platform's templating language. Production patterns beyond the docs cover security (encoding), composition (include vs decorate), and locale-aware rendering. See ISML templates in B2C Commerce: production patterns beyond docs.
Content slots vs content assets. Merchandiser-controllable content has two patterns; picking the right one for each use case prevents content management chaos. See B2C Commerce content slots vs content assets: when each fits.
Forms. Every site has dozens of forms. The SFRA framework is opinionated; the patterns that ship reliable forms cover validation strategy, error rendering, and CSRF. See Forms in SFRA: validation, errors, and persistence patterns.
Phase 3: Server-side architecture
SFRA's request handling sits on three core abstractions: controllers, middleware, and models. The patterns that produce upgradeable code use them all together.
Controllers and middleware. Routes, extension points (append/prepend/replace), middleware composition. See B2C Commerce SFRA controllers and middleware: request shape.
Models and ViewData. The data layer between platform API and templates. Factory pattern, decorator composition, clean data flow. See Models and ViewData in SFRA: the clean data flow.
Schema design. Custom attributes vs custom objects. The choice affects every downstream query and integration. See B2C Commerce custom attributes vs custom objects: schema decisions.
Phase 4: Integrations and APIs
The platform is one node in a real enterprise stack. Three integration concerns:
API choice. OCAPI (older REST API, widely integrated) vs SCAPI (newer Commerce API, headless-friendly). See OCAPI vs SCAPI: choosing the right B2C Commerce API.
External service callouts. Payment gateways, tax engines, OMS, marketing platforms. The services framework wraps these calls with circuit breakers and observability. See B2C Commerce services framework: external callouts at scale.
Platform hooks. The supported extension mechanism for lifecycle events (order created, customer registered, basket calculated). Used right, they survive every platform upgrade. See B2C Commerce hooks: extending without breaking upgrades.
Phase 5: Commerce-specific concerns
Three areas where the commerce engine intersects with site behavior:
Promotions and coupons. Campaign design, qualifier patterns, rule design, and the configurations that scale through Black Friday peaks. See B2C Commerce promotions and coupons: rules that scale at peak.
Search refinements. Faceted navigation, synonyms, query rewrites, search profiles. The configuration that produces relevant results across thousands of queries. See B2C Commerce search refinements: facets, synonyms, rewrites.
Cart and checkout. The highest-revenue and riskiest surfaces. The customizations that survive and the ones that break. See B2C Commerce cart and checkout: the lines you don't customize.
Phase 6: Operations
The work after launch is mostly maintenance, but operational discipline determines whether the site compounds value over time or accumulates technical debt.
Jobs framework. Catalog imports, inventory feeds, customer exports, email batches. The framework that orchestrates batch work, plus the patterns for reliability at scale. See B2C Commerce jobs framework: scheduled and batch work.
Three operational concerns that span the whole stack:
- Performance monitoring. Per-controller latency, search query times, job durations, service call latencies. Dashboards with alerting.
- Code Profiler reviews. Quarterly reviews of slow templates and controllers using the platform's built-in profiler. Refactor opportunistically.
- Pre-peak readiness. For high-volume retail, a documented Black Friday checklist covering promotion configuration, capacity planning, monitoring dashboards, and incident runbook.
Practices that span every phase
A few habits that apply across the whole stack:
- Cartridge structure that scales. Custom code in custom cartridges, vendor code in vendor cartridges, base code untouched. The discipline pays back at every upgrade.
- Source control everything. Cartridges, jobs, metadata exports, all in Git. Business Manager changes that are not in source control are accidents waiting to happen.
- Test in sandbox first. Every code change, every configuration change, every promotion campaign goes through sandbox before production. The cost is low; the catch rate is high.
- Read the platform's release notes. Salesforce ships SFRA improvements and platform updates regularly. Teams that read the notes catch deprecations and capability additions; teams that skip them accumulate surprises.
- Document for the next engineer. The site outlasts any individual on the team. README files in cartridges, decision logs in confluence, runbooks for operations.
Where Sapota fits
Sapota's Salesforce team runs B2C Commerce implementations from greenfield design through long-term maintenance. We have shipped production B2C Commerce storefronts across retail, fashion, and B2B engagements, including SG-to-SFRA migrations and multi-site realm builds.
The engagement model is engineering-heavy. We pair with internal teams or run as a delivery team. We design the cartridge architecture, write the controllers, build the models, configure promotions, set up the jobs, and stay engaged through the first quarter post-launch.
For programs with internal teams that need targeted help, we run scoped engagements: SFRA migrations, performance audits, search tuning, integration design, services framework adoption, and pre-peak readiness reviews.
Implementing B2C Commerce or refactoring an inherited site? Sapota's Salesforce team, certified on B2C Commerce Developer (Comm-Dev-101), handles every phase covered in this guide on production engagements. Get in touch ->
See our full platform services for the stack we cover.
