Connected Storefronts for Salesforce Commerce Cloud

A shopper is choosing a jacket. She wants the right size, her loyalty offer, nearby stock, and a delivery date she can trust. Salesforce Commerce Cloud supports the purchase, but those answers often come from different systems. Your team has to make them work together as one fast, reliable shopping experience.

Harper’s published luxury-retail example describes roughly 20 connected systems, including five internal systems. Recommendations, loyalty, store inventory, content, payments, and shipping all contribute to the experience. This design explores one complex setup: how Harper can bring more of that work together while keeping Salesforce at the center of commerce.

How Harper brings the storefront together

In this design, Harper runs the Next.js storefront alongside the logic and data that help build each page. You can start with one product page and the data it needs, then bring more work together where it helps. The full architecture shows how that setup can grow.

Harper provides the application runtime, database, and caching capabilities. Your team brings selected product, stock, and content records into Harper, so each visit can reuse that information instead of asking every source system again. Harper Fabric manages deployment, data replication, traffic routing, and failover across regions.

Your team implements or adapts the storefront, recommendation logic, offer rules, and delivery estimates. These are examples of application logic running on Harper, rather than packaged retail features included with the platform. Your team also connects source systems, maps their records, and sets freshness and invalidation rules using Harper’s data and caching APIs. Bringing this work together reduces the services around the application. The business rules still need to be defined and tested.

Keep Salesforce, your content management system, and specialist services for the capabilities they already provide. An existing recommendation engine can continue to supply product picks while Harper combines them with current stock and offers. The storefront still connects to Commerce Cloud through Salesforce’s commerce API, SCAPI, and purchase systems remain responsible for final transactions.

The diagram separates Harper’s built-in capabilities, the application work your team owns, and the systems you retain. The boxes inside Harper show where that work runs; they do not each require a separate service to deploy.

Alternatively, use Salesforce’s native headless storefront

Salesforce offers its own headless storefront options, which separate the shopping website from the commerce backend. Storefront Next runs on Salesforce’s Managed Runtime hosting and connects to Commerce Cloud through SCAPI. Salesforce also provides extensions and packaged integrations to add capabilities.

Packaged integrations and services your team already knows can make this a practical choice. The wider retail business still needs to come together: a recommendation engine may suggest a jacket that is unavailable nearby, or the loyalty system may identify the shopper differently from the order system. Your team needs to reconcile those answers in either architecture.

The alternative diagram shows the same business responsibilities arranged across a storefront and separate services. Redis and PostgreSQL are illustrative choices, and suitable logic may run in Salesforce extensions. Compare the integrations you already have, the code you would need to adapt, and the services you would operate. Fewer services can reduce ongoing coordination, but do not by themselves establish which option takes less work to launch.

Where coordination adds up

Each additional service adds something to coordinate: access, data freshness, response time, and recovery when it fails. A page can request several answers at once and still wait for the slowest one. As the stack grows, more development effort goes into keeping the experience consistent across those systems.

Managed Runtime’s proxy rules are one example of the details teams must manage: which systems the storefront can reach and which responses it can cache. The architecture needs clear rules for reusing information, protecting customer data, and handling unavailable services.

Why Harper matters

• Faster decisions within the page. Recommendation and offer logic can run in process with the storefront and its data, reducing waits on separate services.
• Fewer source requests. Reusing current records reduces repeated requests to Salesforce and other systems, easing load on the wider stack.
• Fewer moving parts. The storefront, supporting logic, records, and cache run together, giving your team fewer separate services to operate.
• Simpler regional growth. Fabric manages deployment and traffic across regions, so your team can bring the experience closer to shoppers.

Plan for current, reliable product pages

Start with the logic that benefits most from being close to the storefront and its data. Identify the integrations and rules you can reuse, the code you need to adapt, and the services that should stay where they are. Check that any workloads you move fit Harper’s runtime. Set freshness limits for stock, offers, and delivery estimates, and decide what shoppers see when a source is unavailable.

Keep private customer responses out of shared caches. Final prices, stock reservations, payments, and orders still need checks with the systems responsible for them. Cached information helps build the page; it does not replace those purchase checks.

Related resources

• Bring your whole stack together around Salesforce Commerce Cloud: the broader business case for consolidating the layers around SFCC.

This is one proposed architecture. The right balance of retained systems and Harper services depends on your setup.

• Salesforce Managed Runtime overview
• Storefront Next extensions
• Managed Runtime proxy and caching rules

Start with one product page

Choose one page and one source of delay, such as repeated stock lookups. Keep the other services in place while you test bringing that data and the logic that uses it into Harper. Compare page speed, data accuracy, calls to other systems, and the work required to implement and operate the change. Test what happens when a provider slows down, then decide whether bringing more of the page together is worthwhile. Discuss your architecture with Harper. Bring the systems behind that page and the experience you want shoppers to have.

‍