Salesforce for Retail: Implementation Guide Across Commerce and Service

A retailer scoping Salesforce in 2026 is working from a product map that moved underneath them.

The product most people still call Retail Cloud has been renamed. The product that sounds closest to retail, Consumer Goods Cloud, is built for somebody else entirely. And the capability a retailer actually buys arrives as three separate order-bearing systems that have to agree with each other before a single customer notices anything improved.

None of that is in the brochures, and none of it is in the nine near-identical agency pages that rank for this query. This guide covers what the names mean now, which clouds carry which retail job, where the integration work lands, and how the sequence should run.

Retail Cloud is now Salesforce Point of Sale, and search has not caught up

Start with the naming, because it determines whether you are reading current material or old material.

Salesforce announced Retail Cloud with Modern POS in January 2025, alongside Agentforce for Retail. The POS was not built in-house. Salesforce acquired PredictSpring, a cloud-native retail software vendor, and that acquisition supplies the mobile checkout, clienteling and inventory capability now sold under the Salesforce name.

Then the name changed. Salesforce’s own product FAQ states it plainly: Salesforce updated the name of Retail Cloud to Salesforce Point of Sale. Same capability, different label.

The search data has not followed, and the gap is wide enough to matter when you are briefing a team or searching for guidance. Running the three terms through Google Trends for the United States over the last twelve months gives an average interest score of 53 for “salesforce retail”, 5 for “salesforce retail cloud”, and 0 for “salesforce point of sale”.

Two practical consequences. Anything you find written about Retail Cloud in 2025 describes the product now called Point of Sale, so date-check it before trusting the feature list. And when you brief internally, use both names for at least a year, because half your team learned the old one and the vendor material is inconsistent. Salesforce’s own retail site still carries a Retail Cloud link in its navigation while the product page underneath explains the rename.

Consumer Goods Cloud serves the manufacturer, not the retailer

This is the mis-sale that costs the most, and the search results actively encourage it.

Run a search for Salesforce retail implementation and Salesforce’s own Consumer Goods page ranks on the first page, under a heading about retail execution software. A buyer skimming that result reasonably concludes it is for retailers. It is not.

Consumer Goods Cloud is built for consumer goods manufacturers and distributors, the brands whose products sit on somebody else’s shelves. Salesforce describes it as five solutions: customer planning and forecasting, trade promotion management, retail execution, consumer goods for sales, and consumer goods for service.

Retail execution is the component that causes the confusion. It means a brand’s field representative walking into a store that the brand does not own, auditing shelf placement, checking planogram compliance and taking an order from the store manager. The store in that transaction is the customer. If you are the retailer, you are the store, and this is not your product.

The test is one question. Do you own the point of sale where the consumer transacts? If yes, you are a retailer and your path runs through commerce, service and point of sale. If you sell through someone else’s point of sale, you are consumer goods and your path runs through trade promotion and retail execution. Getting this wrong at scoping produces a data model built around someone else’s business.

Salesforce groups retail capability into five systems rather than one cloud

Salesforce no longer presents retail as a product. It presents it as an architecture, and knowing the frame helps when a proposal arrives organized the same way.

The five named layers are a system of engagement, where teams and agents do the work; a system of insight, carrying the analytics both humans and agents reason from; a system of agency, where agents are built, deployed and governed; a system of work, covering loyalty, point of sale, store operations and personalized shopping; and a system of context, holding real-time federated data so agents act on something trustworthy.

Read it as a scoping checklist, not marketing. Each layer is a budget line and a workstream, and a proposal that covers three of the five has left two to be discovered later. The system of context in particular tends to be underscoped, because unifying customer identity across e-commerce, stores, loyalty and service is the longest pole in most retail programs and the least visible in a demonstration.

Salesforce publishes outcome figures alongside this architecture: a 35 percent increase in productivity, a 10 percent net promoter score improvement, and 60 percent of inquiries resolved by AI. Those are vendor-reported and asterisked on the source page, so treat them as a directional claim from an interested party. The more checkable statement sits next to them on Salesforce’s retail page, that 29 of the top 30 retailers use Salesforce, which tells you less about outcomes and more about why your integration partners will have seen the pattern before.

A retail implementation spans three order-bearing systems that must agree

Here is the architectural fact that decides whether a retail program succeeds, and it is a data problem and not a licensing one.

Retail runs three systems that each believe they own an order. Commerce Cloud, sold for retail as B2C Commerce, creates orders from the website and app. Point of sale creates orders at the register, including transactions that never touch the web. Order Management owns fulfillment, splitting, sourcing and returns across both. Salesforce describes the intent as connecting B2C Commerce with point of sale and order management on one platform, and that connection is the whole project.

The difficulty is that retail transactions refuse to stay in one channel. A customer buys online and collects in store, the pattern retailers call BOPIS. A customer buys in store and returns online, which is BORIS. A single basket contains one item taken off the shelf and one shipped from a distribution center, which Salesforce’s own point of sale documentation calls a mixed cart. Each of those crosses the boundary between two systems that were specified by different teams.

Three questions settle most of the design, and they should be answered before any build starts.

Which system is the master for inventory availability? Store stock, distribution center stock and in-transit stock are usually three different numbers maintained in three different places, and the answer determines what the website is allowed to promise.

Where does the order of record live once a transaction crosses channels? A buy-online-collect-in-store order exists in commerce, point of sale and order management simultaneously, and exactly one of them has to be authoritative for returns.

What is a customer? An email address at checkout, a loyalty number at the register and a phone number given to the contact center are three identifiers for one person, and resolving them is the system of context doing its job.

Teams that leave these open until build discover them during user acceptance testing, which is the most expensive possible moment. The pattern behind that failure mode is covered in why Salesforce implementations fail.

POS and ERP integration set the timeline more than the configuration does

Google’s own People Also Ask box for retail implementation queries carries the question directly: are you integrating an existing point of sale or ERP system. That is the right question, and it is usually the critical path.

Point of sale is the more tractable half, because Salesforce’s offering is deliberately undemanding about hardware. The application runs on standard iOS and Android devices and connects to cash drawers, barcode scanners, receipt printers and common payment terminals, with no proprietary equipment required. It also ships what Salesforce calls a patented offline mode, which keeps the register accepting payments and creating orders without connectivity and syncs when the network returns. Salesforce frames the value in the right terms: stability when foot traffic is highest. A store that cannot transact on a Saturday is losing revenue in real time. Replacing an incumbent POS estate is still a rollout program measured in stores per week, but the integration surface is narrower than most buyers expect.

ERP is the harder half and the one that drags. Retail ERP typically owns product master data, cost, inventory positions and the financial posting of every sale, and MuleSoft is the integration layer most Salesforce retail programs end up standardizing on for it. Salesforce needs product and inventory inbound, and sends orders and returns outbound, so the interface is bidirectional and high-volume. Three things reliably take longer than planned: reconciling the product hierarchy between merchandising and commerce, agreeing how returns post back, and deciding which system owns price.

A fourth system belongs in the same conversation even though it rarely appears in the first scope. Marketing Cloud needs the same customer identity as commerce and service, or personalization runs on a different population from the one the service team sees. Keeping those definitions aligned is a governance problem rather than an integration problem, which is why it belongs with the policies that keep agents and reports honest.

Where GetGenerative.ai fits a retail program

Retail programs are wide before they are deep, and that width is where scoping breaks down.

A retailer is rarely implementing one cloud. Commerce, point of sale, order management, service, loyalty and marketing each carry requirements, each has an existing system behind it, and the integration between them is where the cost concentrates. Specifying that breadth accurately is a discovery and design problem, and doing it in workshops alone takes months a seasonal business does not have.

The Discovery agent turns store, contact center and merchandising sessions into structured requirements instead of notes. The Design agent converts those into stories and solution outlines detailed enough to estimate against, which matters more in retail than elsewhere because the integration count drives the number. The Metadata agent reads what already exists in the org, so a multi-cloud retail scope is priced against real configuration instead of assumptions. The Test agent builds the case library that cross-channel flows demand, since buy-online-collect-in-store needs testing in both directions.

Teams wanting the delivery side scoped against a real retail architecture can look at how our Forward Deployed Engineers run multi-cloud programs.

Store associates and contact center agents need the same customer record

The service half of a retail program is where the commerce investment either converts into loyalty or does not.

A customer who ordered online, had a delivery problem, called the contact center, then walked into a store expects the associate to know all of it. That expectation is reasonable and it is also the hardest thing on the list, because the associate is working on a handheld device during a two-minute interaction while the contact center agent has a full console and five minutes.

Salesforce’s point of sale carries clienteling features aimed at this: associates can look up an existing customer or create one at the register, and view profile detail including loyalty data and purchase history. The capability exists. Whether the associate sees anything useful depends entirely on whether the system of context actually resolved that customer across channels, which returns to the identity question above.

Two design decisions follow from the handheld constraint. Decide what the associate sees in the first screen, because a profile that requires three taps during a queue will not be used. And decide what the associate is allowed to do, since issuing a goodwill credit at the register is a different risk posture from the same action in a supervised contact center.

Subvertical shapes the data model before any cloud is chosen

The People Also Ask box asks which retail sector you are in, and the question is not idle.

Salesforce segments its own retail material by subvertical, naming fashion and restaurants among them, and the differences are structural, not cosmetic.

Fashion carries size and color variants, so a single product generates dozens of sellable units and returns run at rates that would alarm a grocer. The data model has to handle variant hierarchy from the start, and the returns process is a primary flow rather than an exception.

Grocery runs on high basket frequency, low basket value, substitutions and perishability. Personalization works off purchase cadence instead of browse behavior, and a substitution rule is a customer experience decision disguised as an inventory rule.

Restaurants and food service bring franchise structure, which changes the ownership model: the brand does not control every location, so data sharing, promotion compliance and who owns the customer become contractual questions before they are technical ones.

Specialty retail with high-consideration products leans on clienteling and appointment flows, where the associate relationship carries more weight than the recommendation engine.

The decision this drives is sequencing. A fashion retailer that builds commerce before settling the variant model rebuilds it. A grocer that builds personalization on browse data gets poor results and blames the algorithm. Establishing the subvertical shape belongs in discovery, ahead of the implementation plan that the phased plan template lays out.

Retail agents work the gaps between channels

Agents earn their place in retail where the handoffs are, which is also where the margin leaks.

The useful retail cases are specific. Order status and delivery exceptions, which generate contact volume that is high in count and low in complexity. Returns and exchanges initiation, where policy is rule-driven and the customer mainly needs to know what will happen. Product and availability questions, where the answer depends on real-time inventory the human cannot see quickly. And associate-facing assistance, where the agent reads the customer history so the associate does not have to navigate for it.

Two constraints belong in the plan rather than in the pilot retrospective.

Grounding quality decides answer quality. An agent answering availability questions against stale inventory produces confident wrong answers, which in retail means a customer travelling to a store for something that is not there. The system of context is a prerequisite for the system of agency, not a parallel workstream.

Consumption cost rises with success. Retail volumes are large and seasonal, so an agent that handles order status well in October handles substantially more of it in December, and the cost line moves with it. Anyone putting an agent into a retail business case should model that against how Agentforce consumption is actually metered rather than a flat per-user assumption, and carry the result into the business case itself.

Sequencing backwards from the freeze

Retail has an immovable constraint that most industries do not: a change freeze around peak trading, which in the United States means the Black Friday through holiday window, and a hard commercial penalty for getting it wrong.

Work backwards from that date. Establish the subvertical data model and customer identity first, because everything else assumes them. Build one channel to production instead of all channels to pilot, since a working commerce site teaches more than three half-finished ones. Take point of sale to a small number of stores before the estate, because store rollout is a logistics exercise with its own failure modes. Put one agent use case into the first release specifically because retail agent activity is logged, which makes it the easiest benefit in the whole program to prove.

And treat the freeze as a design input and not a schedule risk. A program that plans to go live in November is a program that goes live in February.

Questions retailers ask about implementing Salesforce

Is Salesforce Retail Cloud still available?

Yes, under a different name. Salesforce states that it updated the name of Retail Cloud to Salesforce Point of Sale, and the capability set carried over, covering in-store checkout, inventory and omnichannel fulfillment. Material written before the change still uses the Retail Cloud name.

Which Salesforce products does a retailer need?

Typically B2C Commerce for digital selling, Point of Sale for stores, Order Management for fulfillment across both, Service Cloud for support, and Data 360, still widely referred to by its former name Data Cloud, for the customer identity that ties them together, with Marketing and Loyalty where relevant. The combination is determined by whether you sell through stores, digital or both.

What is the difference between Salesforce for Retail and Consumer Goods Cloud?

Retail solutions serve the retailer who owns the point of sale where consumers transact. Consumer Goods Cloud serves manufacturers and distributors selling through someone else’s stores, and its retail execution component covers field reps auditing shelves and taking orders in those stores.

Does Salesforce Point of Sale need special hardware?

No. It runs on standard iOS and Android devices and works with common retail peripherals including cash drawers, barcode scanners, receipt printers and payment terminals. It also includes an offline mode that continues processing transactions during a network outage and syncs afterwards.

What usually takes longest in a retail Salesforce implementation?

Integration, not configuration. ERP interfaces for product, inventory and financial posting, plus resolving customer identity across commerce, stores, loyalty and service, consistently consume more effort than building the channels themselves.

Where do AI agents fit in a retail deployment?

In the high-volume, low-complexity contact that clusters around orders: status and delivery exceptions, returns initiation, availability questions, and associate-facing lookups. Agent answers are only as good as the inventory and customer data behind them, so grounding has to be in place first, and consumption cost rises with seasonal volume.