Salesforce Commerce Cloud Consulting and Development

Salesforce Commerce Cloud, still widely called Demandware, is an enterprise SaaS ecommerce platform owned by Salesforce and used mainly by large retailers and global brands for B2C. It includes Einstein AI for product recommendations and search, a multi-site architecture for running many storefronts from one instance, and native integration with the wider Salesforce suite including Service Cloud and Marketing Cloud. What distinguishes it from other SaaS platforms is depth of customisation: almost any behaviour can be overridden through cartridges, including checkout, which most hosted platforms do not permit. The trade-off is licensing priced against gross merchandise value, so cost scales with your revenue whether or not you use more of the platform, and a development cycle that requires specialists rather than general web developers.

SFRA, the Salesforce Reference Architecture, is the officially recommended storefront architecture for SFCC. It replaced the older SiteGenesis approach with a modular, cartridge-based structure designed so that customisations sit in your own cartridges rather than in modified core files. That distinction is the whole point. When customisations live in overlay cartridges, Salesforce platform updates and third-party cartridges can be applied without conflict. When someone has edited base templates directly, every update becomes a manual reconciliation and teams stop updating, which accumulates security and compatibility debt. Implementations that follow SFRA properly are dramatically cheaper to maintain over a five-year horizon, and the difference is almost entirely invisible on launch day. It is the most common thing we find done badly when taking over an inherited SFCC build.

Einstein Product Recommendations analyses purchase history, browsing behaviour, and product attributes to serve personalised suggestions across the storefront, while Einstein Search improves discovery by interpreting intent rather than matching keywords exactly. Both accept business rules, so you can control which products can be recommended in which contexts and exclude items that are out of stock, end-of-line, or inappropriate to pair. Two practical caveats. Einstein needs traffic before its output is good, so a new storefront or a freshly migrated one goes through a cold-start period of weeks, and judging it before then is misleading. And its recommendations are only as sensible as your product data, so incomplete or inconsistent attributes produce poor pairings that look like a model problem but are a catalogue problem. Fix the data first.

Yes, and it is one of the stronger reasons to be on SFCC at all. Service Cloud integration gives your support team access to order history and status inside the case they are working, which removes the most common cause of slow resolution. Marketing Cloud integration lets commerce events such as abandoned carts, purchases, and back-in-stock trigger transactional and marketing journeys. We also build Sales Cloud integrations where B2C customer data feeds a B2B sales process. The decision worth making early is which system is authoritative for customer records, because both platforms will happily hold a version and they will diverge. Defining that upfront, along with the conflict rules for when both change the same field, is far cheaper than reconciling duplicate customer records eighteen months later.

Both, and taking over an existing implementation is the more common engagement. When we inherit an SFCC build we start by mapping the cartridge path, because the order cartridges override each other in is where most unexplained behaviour originates, and it is rarely documented. We then assess code quality against SFRA conventions, catalogue what has been customised, and produce a written view of what is sound, what is risky, and what is simply unused. That document is useful to you regardless of who does the work afterwards, including your existing partner. We also build new implementations from scratch on SFRA. If you are currently being told a problem is inherent to the platform, an independent read is usually worth having before accepting that.

OCAPI, the Open Commerce API, is the older REST interface and remains widely used across existing integrations. SCAPI, the Salesforce Commerce API, is the newer and more performant option that Salesforce is positioning as the future direction. For new integrations we default to SCAPI where the required endpoints exist, and continue maintaining OCAPI on existing implementations rather than rewriting working code without reason. The important qualifier is that SCAPI does not yet cover everything OCAPI does, so a wholesale migration is often not possible even when it is desirable, and hybrid implementations using both are normal rather than a sign of poor design. If you are hitting rate limits, migrating the specific high-volume calls to SCAPI usually helps more than a full rewrite.