How to excel with SFCC PWA kit when running your business with oracle is less about forcing two enterprise platforms to talk directly to each other and more about giving each system a clear job. Salesforce B2C Commerce should remain the commerce engine that understands shoppers, products, baskets, promotions, checkout, and orders. PWA Kit should remain the customer-facing application layer. Oracle should continue doing the back-office work your organization has chosen it to do, such as financials, fulfillment, inventory, order orchestration, or other enterprise processes. The architecture becomes easier to operate when those boundaries are explicit.

That distinction matters because PWA Kit is not simply a new theme for an SFCC storefront. Salesforce describes PWA Kit as an open-source framework for building a React storefront, with server-side rendering and client-side navigation, while Managed Runtime provides the infrastructure used to deploy, host, and monitor the application. The Retail React App gives teams a starting point for product listing pages, product detail pages, cart, checkout, routing, styling, testing, and progressive-web-app features. In other words, the storefront is a real application tier rather than a collection of templates rendered by a traditional SFRA controller.

At the same time, Salesforce’s current composable architecture expects the storefront to consume B2C Commerce through the Salesforce Commerce APIs, commonly called SCAPI. The @salesforce/commerce-sdk-react package provides React Query-based hooks for fetching, caching, and mutating B2C Commerce data, and Shopper Login and API Access Service, or SLAS, handles shopper authentication and token management. That gives PWA Kit a supported path into product, search, basket, customer, checkout, order, promotion, and shopper-context capabilities without requiring the browser to understand the internal details of the commerce platform.

Oracle belongs in this picture, but usually behind the commerce boundary rather than inside every storefront interaction. Oracle Integration 3 currently includes a dedicated Salesforce Commerce Cloud Adapter. Oracle documents that adapter as an invoke connection capable of Create or Update, Query, and Delete operations against Salesforce Commerce Cloud, including custom objects. Oracle also documents support for OAuth 2.0 two-legged authentication and the Salesforce Commerce Cloud Data and Shop APIs. That makes Oracle Integration a legitimate integration layer for supported SFCC operations, but it is important not to confuse Oracle’s Salesforce Commerce Cloud Adapter with PWA Kit’s SCAPI-facing storefront architecture.

The architecture that keeps the storefront fast

A clean implementation generally looks like this:

Shopper
   |
   v
PWA Kit / Managed Runtime
   |
   |  SCAPI + SLAS
   v
Salesforce B2C Commerce
   |
   |  integration workflows
   v
Oracle Integration
   |
   v
Oracle ERP / Order / Inventory / Financial Systems

The most important line in that diagram is the one between PWA Kit and Salesforce B2C Commerce. Normal shopper traffic should use the commerce APIs designed for the storefront. A product detail page should not have to synchronously call an Oracle ERP system just to render a price or decide whether the Add to Cart button can appear. A basket request should not become dependent on three enterprise systems responding before the shopper can continue.

Instead, commerce-critical data should be made available in SFCC in the form required by the storefront. Oracle-backed systems can remain authoritative for the data they own, but integration processes should synchronize or expose that data through deliberate contracts.

Consider inventory. If Oracle is your enterprise source for inventory availability, that does not automatically mean a PWA product tile should query Oracle every time it renders. A more resilient design is to establish how inventory moves from the Oracle side into the commerce platform, how often it changes, what latency the business can tolerate, and which system owns the final sellability decision. PWA Kit can then consume the resulting commerce-facing availability through the supported B2C Commerce APIs.

The same principle applies to price, customer data, fulfillment status, and order information: decide which platform owns the record, decide what SFCC needs in order to transact, and then integrate at the system boundary.

Use SCAPI for the shopper experience

Salesforce’s Shopper APIs are specifically organized around common storefront activities. Current documentation identifies APIs for product search, product detail data, promotions, baskets, login, customer addresses, checkout, orders, and shopper context. PWA Kit’s Commerce SDK React library adds hooks, token handling, server-side data fetching support, cache behavior, and mutations around those APIs.

That has an architectural consequence: if the storefront already has a supported SCAPI operation for a commerce use case, use it rather than creating an Oracle-backed shortcut around B2C Commerce.

For example, a product page flow can remain straightforward:

PWA product page
      |
      v
Commerce SDK React hook
      |
      v
Shopper Products API
      |
      v
Salesforce B2C Commerce

If Oracle owns information needed to produce that product’s commerce state, integrate that information into the commerce layer independently.

This separation improves more than performance. It also keeps promotions, customer context, basket state, authentication, and checkout behavior inside the platform that understands those concepts.

Treat Oracle Integration as an integration tier, not a storefront API

Oracle Integration is well suited to orchestration, mapping, transformation, scheduled integrations, REST endpoints, and adapter-driven connectivity. Oracle’s current documentation also shows that the REST Adapter can be configured as a trigger, while the Salesforce Commerce Cloud Adapter itself is documented as an invoke-only adapter.

That distinction is worth designing around.

For an Oracle-to-SFCC flow, Oracle Integration can orchestrate work and invoke Salesforce Commerce Cloud through its dedicated adapter where the supported Data or Shop API operation fits the requirement.

For an SFCC-to-Oracle workflow, do not assume that the Salesforce Commerce Cloud Adapter can simply sit there waiting for SFCC events; Oracle explicitly documents it as unable to act as the trigger connection. A common Oracle Integration pattern is therefore to use another supported trigger mechanism—such as a REST-triggered integration or a schedule—and then use the appropriate downstream Oracle adapters and services.

The actual trigger should match the business requirement. Some data needs near-real-time delivery. Other data is safer and cheaper to process in controlled batches. The right answer is usually determined by business latency, recovery requirements, API limits, and ownership rather than by what is easiest to wire together on day one.

An order should have a clear lifecycle

Orders are where integration architectures are most likely to become tangled.

The shopper’s checkout transaction belongs in the commerce experience. PWA Kit uses the B2C Commerce shopper APIs for baskets and order submission, and SFCC should provide the shopper with a deterministic result for that commerce transaction.

Afterward, the enterprise order lifecycle may move into Oracle systems for fulfillment, financial processing, allocation, or another business-specific workflow. That handoff should be designed as a durable integration, not as an accidental side effect of a React component.

A robust order flow asks several questions before anyone writes code:

• What constitutes successful order placement in SFCC?
• When is the Oracle-side order created?
• What identifier correlates the SFCC order with its Oracle representation?
• What happens if Oracle is temporarily unavailable?
• Can the integration safely retry without creating a duplicate order?
• Which status changes need to return to SFCC?
• Which system is authoritative for cancellation, fulfillment, and refund state?
• How are failed messages surfaced to operations teams?

Those questions are more important than the shape of any individual API call.

A commerce site should not tell a shopper that checkout failed merely because an asynchronous enterprise fulfillment system had a temporary outage after the commerce order was successfully accepted. Likewise, an integration should never create a second enterprise order simply because a request was retried. Idempotency, correlation IDs, retry rules, and observable failure states should be part of the design from the beginning.

Keep server-side rendering free of unnecessary enterprise dependencies

One of PWA Kit’s key architectural features is that the same application supports server-side rendering for the initial experience and client-side behavior for subsequent navigation. Managed Runtime executes the application in a Node.js environment with Express-based application-server behavior for the Retail React App architecture.

That makes it tempting to use the server side as a convenient place to call every backend system. Resist that temptation.

Every synchronous dependency added to server-side rendering can affect:

• time to first byte,
• cacheability,
• failure rate,
• timeout behavior,
• peak-season scalability,
• and the ability to isolate an Oracle outage from the storefront.

Salesforce specifically documents CDN caching as an important performance advantage for server-rendered PWA Kit pages. If a page requires a personalized or volatile Oracle request every time it is rendered, you can easily undermine that advantage.

Use the PWA server tier to orchestrate the shopper experience, not to recreate an enterprise service bus.

Be deliberate about caching

PWA Kit and Commerce SDK React already give developers caching tools. The question is not simply whether data can be cached, but where the truth belongs and how stale it is allowed to become.

Product descriptions and relatively static merchandising content have a very different freshness profile from available-to-sell inventory. A fulfillment ETA may have a different freshness requirement from a category description. Customer-specific information should not accidentally become shared cache content.

For Oracle-derived data, document at least:

That table is not a Salesforce or Oracle prescription; it is an architecture exercise every implementation should complete.

Authentication deserves its own design

PWA Kit shopper authentication is built around SLAS. Salesforce documents SLAS as the mechanism securing Shopper API access, with support for guest access and customer identity flows. Current PWA Kit compatibility guidance is version-sensitive, and recent releases have changed requirements around private clients, channel_id, hybrid authentication, and related packages.

Do not copy authentication configuration from an old implementation without checking the compatibility matrix for the exact PWA Kit, Retail React App, Commerce SDK React, and hybrid-auth versions you are deploying.

Oracle Integration’s Salesforce Commerce Cloud Adapter has a different authentication responsibility. Oracle documents OAuth 2.0 two-legged authentication for the adapter. These are separate trust relationships serving different audiences:

Shopper / PWA Kit -> SLAS -> Shopper APIs

Oracle Integration -> machine-to-machine credentials -> SFCC integration APIs

Keeping those credentials and purposes separate makes the architecture easier to secure and reason about.

Do not assume “Salesforce API” means one API

SFCC has evolved through multiple API families, and that creates easy opportunities for confusion.

PWA Kit’s modern shopper-facing architecture is centered on SCAPI and SLAS. Oracle’s current Salesforce Commerce Cloud Adapter documentation specifically describes support for Salesforce Commerce Cloud Data and Shop APIs. Those terms are associated with the established SFCC API surface commonly used for system integrations.

That means you should validate every proposed integration against the exact API family supported by the tool in question.

Do not write an architecture diagram that says:

Oracle Adapter -> SCAPI

unless the specific Oracle adapter version and operation you are using explicitly supports that API.

Instead, document it accurately:

PWA Kit -> SCAPI / Shopper APIs

Oracle Integration Salesforce Commerce Cloud Adapter
    -> supported Salesforce Commerce Cloud Data / Shop API operations

That small distinction can prevent a large amount of implementation confusion.

Version compatibility is part of the architecture

PWA Kit is actively developed, and Salesforce publishes a compatibility matrix because PWA Kit, Retail React App, Commerce SDK React, Commerce SDK Isomorphic, SLAS-related cartridges, and hybrid-auth capabilities do not all move in lockstep.

Treat that matrix as a deployment requirement.

Before an upgrade:

1. Identify the exact versions currently deployed.
2. Check the current Salesforce compatibility matrix.
3. Review release notes for authentication and API changes.
4. Test server-side rendering and hydration.
5. Test login and guest sessions.
6. Test basket persistence.
7. Test checkout.
8. Test Oracle-connected integration paths separately.
9. Promote through Managed Runtime environments rather than testing first in production.

Managed Runtime explicitly supports separate environments for development, testing, and production, so use that separation to test both storefront code and integration configuration before promotion.

Observability is what turns an integration into an operational system

The hardest bugs in a composable architecture are often not coding bugs. They are failures where every individual platform claims success but the business transaction never completed.

Give each transaction a traceable identity.

For an order, preserve identifiers such as:

SFCC order number
integration instance/correlation ID
Oracle order identifier
timestamps for each handoff
final processing state

Do the same for important inventory, customer, and pricing workflows where appropriate.

Operational teams should be able to answer:

The shopper placed order 12345. Did Salesforce accept it? Did the integration process it? Did Oracle create it? If not, where did it stop?

If answering that question requires three developers searching unrelated log files, the integration is not finished.

A practical implementation strategy

Teams trying to modernize an existing SFCC-and-Oracle estate do not have to replace everything at once.

A sensible progression is:

1. Establish the commerce API boundary

Build PWA Kit against supported B2C Commerce APIs and SLAS. Keep shopper logic inside SFCC wherever practical.

2. Inventory existing Oracle dependencies

Document every current flow involving:

• products,
• inventory,
• pricing,
• customers,
• orders,
• fulfillment,
• cancellations,
• refunds,
• financial postings,
• and reporting.

Classify each as synchronous, asynchronous, scheduled, or manual.

3. Decide system ownership

For every important business object, identify the authoritative system and what representation SFCC needs to transact.

4. Put integration logic in the integration layer

Use Oracle Integration, SFCC integration capabilities, and explicit APIs for system-to-system processes. Avoid embedding enterprise integration rules throughout React components.

5. Make failure recoverable

Design retry behavior, duplicate prevention, reconciliation, and operational alerts before launch.

6. Test peak behavior

A storefront that works with ten test orders can still fail during a promotion if synchronous dependencies, API limits, or slow integrations become the critical path.

7. Upgrade components intentionally

Use Salesforce’s current PWA Kit compatibility documentation rather than assuming independent package upgrades are safe.

What excellence actually looks like

The best SFCC PWA Kit and Oracle implementation is not the one with the most direct connections. It is the one where responsibilities are obvious.

PWA Kit owns the customer experience.

Managed Runtime owns the deployment and runtime environment for that storefront.

SCAPI and SLAS provide the supported shopper-facing connection to B2C Commerce.

Salesforce B2C Commerce owns the commerce transaction and the storefront-facing state required to execute it.

Oracle systems remain authoritative for the enterprise functions assigned to them.

Oracle Integration orchestrates the system-to-system work for which it is designed.

When those boundaries are respected, How to excel with SFCC PWA kit when running your business with oracle stops being a question about connecting two brands of enterprise software. It becomes a disciplined composable-commerce architecture: keep the shopper path fast, keep system ownership explicit, keep integrations recoverable, and make every critical business transaction observable from end to end.

Official documentation referenced

The technical assertions in this article were checked against current Salesforce and Oracle documentation available in September 2026:

• Salesforce — PWA Kit Overview: https://developer.salesforce.com/docs/commerce/pwa-kit-managed-runtime/guide/pwa-kit-overview
• Salesforce — Managed Runtime Overview: https://developer.salesforce.com/docs/commerce/pwa-kit-managed-runtime/guide/mrt-overview.html
• Salesforce — B2C Commerce API / SCAPI: https://developer.salesforce.com/docs/commerce/commerce-api/guide/scapi-get-started.html
• Salesforce — PWA Kit Compatibility Matrix: https://developer.salesforce.com/docs/commerce/pwa-kit-managed-runtime/guide/compatibility-matrix.html
• Salesforce — Commerce SDK React: https://salesforcecommercecloud.github.io/pwa-kit/
• Oracle — Using the Salesforce Commerce Cloud Adapter with Oracle Integration 3: https://docs.oracle.com/en/cloud/paas/application-integration/sforce-commerce-adapter/index.html
• Oracle — Salesforce Commerce Cloud Adapter Capabilities: https://docs.oracle.com/en/cloud/paas/application-integration/sforce-commerce-adapter/salesforce-commerce-cloud-adapter-capabilities.html
• Oracle — Using the REST Adapter with Oracle Integration 3: https://docs.oracle.com/en/cloud/paas/application-integration/rest-adapter/index.html