Platform & Architecture

Acquisitions

Integrating Demandware with Salesforce

Demandware became B2C Commerce Cloud. It does not run on the core platform. The objects are the catalogue, the price book, and the storefront.

Staff working a warehouse or retail floor.Platform & Architecture

A shopper sees one price. The price book holds another. Someone in the meeting pastes a spreadsheet of products into Sales Cloud and calls the paste the Demandware integration. The storefront does not change. The spreadsheet has no catalogue, no price book, and no storefront on it. B2C Commerce does not run on the core platform. A Salesforce sandbox does not clone it. The picture on the slide has two boxes and a line, and the line does not say what happens when the call fails. It is a poster. This page names the system, the objects, and the failure, and it leaves the cutover to the other page.

The person who can open the store is not in the spreadsheet. Until they can point at a product in the catalogue, a price in the price book, and the same product on the storefront, there is no integration to repair. There is a file. A file is not a shop.

The app

The app is B2C Commerce Cloud. The record this page cites says where Demandware went, and this page quotes that sentence once: "In 2016, the company acquired Demandware, which later became B2C Commerce Cloud."

B2C Commerce does not run on the core platform. The core org has its own records. The commerce instance has a catalogue, a price book, and a storefront. Owning both under the Salesforce name does not make them one app. A seller looking at an opportunity is not looking at the shop. Write B2C Commerce on the diagram as its own system. If the only system on the diagram is Sales Cloud, the diagram is about a different product.

A search for a Salesforce Demandware app is a search for that commerce instance, under the name people still type. The bookmark may say Demandware. The place the shop runs is B2C Commerce Cloud. Use the current name when you mean the app. Use Demandware when you mean the word on the old diagram. Do not use either word for a spreadsheet.

Open the app before you draw it. A person who cannot show the catalogue, the price book, and the storefront has not found the app. A login to the core org is not that demonstration. Send them to open the shop. The architecture can wait until they have.

The connector

The objects are the catalogue, the price book, and the storefront. Those three are what this page will treat as the integration. The catalogue is the set of products the shop can sell. The price book is the price those products carry. The storefront is what the shopper sees. A connector that does not name all three has not named the shop. It has named a list.

A spreadsheet into Sales Cloud is not the integration. Sales Cloud can hold a row. A row is not a catalogue, it is not a price book, and it is not a storefront. Loading the row does not publish the shop, and it does not keep the price the shopper sees in step with the price book. If the proposal's method is a file into an opportunity, a product object, or a custom object on the core platform, it is the spreadsheet under another heading. Decline it.

This page does not name a connector product, an API, a daily cap, a middleware SKU, or a price. The record does not name them. A slide that adds a branded connector has invented a thing you cannot check here. The connector, on this page, is the path that carries the catalogue and the price book through to the storefront. If you cannot say which product, which price, and which page on the shop, you do not have that path yet.

Write one sentence. This product in the catalogue, at this price in the price book, appears on this storefront. If the sentence uses "the data" instead of a product, it is not finished. If it ends in Sales Cloud, it is the spreadsheet. Start again from the shop.

The architecture

The architecture has one system and three objects, plus the failure. The system is B2C Commerce. The objects are the catalogue, the price book, and the storefront. The failure is that the call does not land, so the storefront does not match the catalogue and the price book. Draw that. A second system called Sales Cloud may sit nearby for a sales process. It is not the shop, and an arrow from the shop into a spreadsheet does not make it the shop.

What the picture must sayWhat you write
SystemB2C Commerce, which does not run on the core platform
ObjectThe catalogue, the price book, and the storefront
FailureThe call does not land, so the storefront does not match

A Salesforce sandbox does not clone B2C Commerce. A full copy, a partial copy, and a developer copy are shapes of a core sandbox. None of them is a second shop. Refreshing the sandbox does not copy the catalogue, does not copy the price book, and does not publish the storefront. Anyone who says the sandbox already contains the store should open the org and show the shop. The absence is the finding.

Do not draw Marketing Cloud, a middleware box, or a fee on this picture. They are not the shop. A guide book is not the picture either. People search for a Salesforce Demandware integration guide book because they want the shop drawn for them. This page will not invent that book. The picture is finished when the three objects are names from your catalogue, your price book, and your storefront.

When the call does not land

The failure is a call that does not land. The catalogue and the price book say one thing. The storefront shows another, or it shows nothing. That gap is the integration fault. Write the product, the price the price book holds, the price or the absence on the storefront, and the time you looked. A ticket that says the commerce integration is down, without those, has not named the failure.

Walk the three objects in order. Is the product in the catalogue? Is the price in the price book the price you expected to publish? Does the storefront show that product at that price? The first no is where the call failed. Do not skip to a theory about the core platform. B2C Commerce does not run on the core platform, so a fault in the shop is not repaired by editing a lead.

If the call never left a spreadsheet, it did not fail in B2C Commerce. It was never the integration. Say that plainly. The storefront was never asked to change. Loading more rows into Sales Cloud will not make the call land. Close the spreadsheet work as a separate list, if you still want the list, and return to the catalogue.

Do not invent an error code, a retry limit, or a queue name. If the shop shows a status for that product, write the status you saw. If it shows nothing, write that it showed nothing. Nothing is a result. It is not a reason to name a connector product so the incident looks technical.

An integration names three things

An integration exists only when the page can name the system, the object, and what happens when the call fails. A diagram that does not name those three is a poster.

Here the system is B2C Commerce. The objects are the catalogue, the price book, and the storefront. The failure is that the call does not land, so the storefront does not match. A proposal that cannot say those sentences is not a Demandware integration. A proposal whose object is a spreadsheet in Sales Cloud is the thing this page refuses. Take it off the board in the meeting. You do not need a second workshop to see that the shop is missing.

The same test rejects a sandbox plan. If the method is a sandbox type, the method is still about the core org. A Salesforce sandbox does not clone B2C Commerce. The test also rejects a single box labelled Salesforce, with Demandware written underneath as a mood. The shop is its own system. Say so, then name a product.

Keep the three sentences at the top when the picture grows. A box for orders, tax, or inventory has to be a real object in your shop, named by someone who has opened it. This page will not invent those objects. If you cannot open them, they do not go on this diagram. The catalogue, the price book, and the storefront are enough to prove you have found the app.

The other two pages

This page is not the implementation page, and it is not the page about what happened. The catalogue cutover, the price book work, and the storefront change are implementation. That scope is on the Demandware implementation page. The purchase, the owner, and the missing end date are on what happened to Demandware. Stay here when the question is the app, the objects, the architecture, and the call that does not land.

Do not answer a price mismatch with a history of the acquisition, and do not answer it with a rebuild of the core org. The shopper's price is a call that did or did not land. This page tells you how to name that call. The other pages tell you what was bought, and what a change to the shop includes, if you decide to change it. Link them. Do not fold them into one fee. This page will not print a fee.

A partner who brings a guide book, a sandbox refresh, and a spreadsheet has missed the shop. The book does not know your catalogue. The sandbox does not clone B2C Commerce. The spreadsheet is not the storefront. Ask them to open the price book and read one price aloud, then open the storefront and read the same product. If those two readings differ, you have the failure. If they cannot open either, they are early.

Write one product, one price-book price, and what the storefront showed, with the time. If you cannot write it, you have not started. Open B2C Commerce. Find the catalogue. Find the price book. Find the storefront. Then say whether the call landed. The poster can come down. The shop cannot be replaced by a file in Sales Cloud.

When the three match, there is no fault to invent. When they do not, the fault is the call that did not land, on a named product, in B2C Commerce. That is the incident. It is not a reason to move the shop onto the core platform, and it is not a reason to price a connector this page does not name. Say the product, the price, and the storefront. Then stop.

Sources

  1. The ultimate guide to Salesforce product rebrands

Common questions

Answered, directly.

The questions this piece settles about Platform & Architecture, answered in full on this page.

B2C Commerce Cloud. B2C Commerce does not run on the core platform. A Salesforce sandbox does not clone it. Sales Cloud is not the shop.

The system, the objects, and the failure. The system is B2C Commerce. The objects are the catalogue, the price book, and the storefront. The failure is a call that does not land. Without those, the diagram is a poster.

The catalogue, the price book, and the storefront in B2C Commerce, with a stated failure when the call does not land and the storefront does not match. A spreadsheet into Sales Cloud is not that integration.

The path that carries a named product from the catalogue and the price book onto the storefront. This page does not name an API, a middleware SKU, a daily cap, or a price. A file loaded into Sales Cloud is not the connector.

This page is not a book, and it will not invent one. The integration is your catalogue, your price book, and your storefront. Implementation and the purchase are the other two pages.

Free architect conversation

Talk to an architect, not a sales rep.

Architecture review, before it gets expensive. 60 seconds to brief us, and a certified architect replies within one business day.

What decision is actually in front of you?

Pick the closest fit. The review is free, and we will tell you to keep your current design if keeping it is right.

What does this decision touch?

Optional. Choose any that apply, or skip ahead.

Where does your org stand today?

Optional. A few sentences is plenty: what is working, what is stuck, and what you want to be true. Or skip ahead and tell us on the call.

Who should the architect reach?

A certified architect will reply to these details.

Takes about 30–60 seconds · No obligation · Architect replies within one business day

Protected by reCAPTCHA. Google's Privacy Policy and Terms apply.

More from Insights

Read by desk

Ten desks, one delivery team. Every piece is written by the people who do the work.