I moved into Salesforce B2B Commerce after a few years living mostly in Sales Cloud and Service Cloud, and I’ll be honest: I assumed my existing skills would carry over cleanly. Most of them did. What tripped me up early wasn’t the hard technical parts. They were the quiet assumptions I didn’t know I was making.
One clarification before we start, because the naming confuses a lot of people. This is about B2B Commerce built on the core Salesforce (Lightning) platform, the version that runs on Experience Cloud. It is not B2C Commerce (formerly Demandware), which is a separate platform with its own architecture. If that’s what you’re working on, most of what follows won’t map to your world.
Key Takeaways
- Portal users start as Contacts on an Account; Enable Customer User creates the login.
- External users run on cheaper Experience Cloud licenses (usually Customer Community Plus) and sign in through the storefront, not your org.
- The customer-facing store is built in Experience Cloud, separate from your internal setup.
- External record access comes from OWD (including External OWD) plus Sharing Sets, and the license tier changes what’s possible.
- Product and pricing access is a separate system: Buyer Account → Buyer Group → Entitlement Policy + Price Book.
Table of Contents
Portal users start with a Contact, not a User
Coming from internal Salesforce work, my instinct was to create a User. Someone needs access, so you create a user, right? Not here.
In B2B Commerce, a portal user starts as a Contact, and that Contact must be tied to an Account before anything else works. Once it’s in place, you use the standard Enable Customer User action on the Contact. Salesforce then creates the actual user record and grants portal access.
It sounds like a minor detail. It isn’t. If you try to create a user directly, you will waste a lot of time wondering why you can’t find the option you expected.
Portal users aren’t the same as internal Salesforce users
The second thing that caught me: external users run on a completely different license type from your internal team.
Experience Cloud external licenses are designed for customers accessing a storefront or portal, and they cost far less than a full internal Salesforce license. That price difference is why they exist. It makes it realistic to give portal access to thousands of buyers without licensing costs getting out of hand. In practice, B2B buyers are usually assigned Customer Community Plus because the cart, checkout, and advanced sharing they need generally call for that tier rather than the basic one.
There’s a second half to this. Portal users don’t log into your org the way you do. They come in through the storefront’s external experience, with only the access you’ve defined for that site. When you’re chasing down a “why can’t this user see X” problem, that distinction saves real time. I found that out the slow way.
The Storefront lives in Experience Cloud, not the standard org
When you work inside Salesforce all day, you get used to changing things in one place: Lightning App Builder, page layouts, flows, the usual setup menus. Then a customer asks you to change something on the store, you go looking for it in the org, and it’s just… not there.
That’s because the storefront is built and managed in Experience Cloud, through Experience Builder. Pages, navigation, components, branding, the whole customer-facing experience gets configured there, separately from your internal Lightning setup.
The org and the store are connected, and they share data. But they’re two different surfaces. Knowing which one owns the thing you’re trying to change is honestly half the job.
Record access follows a different set of rules
This is the one I wish someone had sat me down and walked through on day one.
If your mental model of access is profiles, permission sets, roles, and sharing rules, that model only carries you partway with external users. Experience Cloud adds its own sharing layer on top. Two pieces matter most:
- Organization-Wide Defaults (OWD) set the baseline. There is also a separate external OWD, and it must be equal to or stricter than your internal OWD. Check it promptly.
- Sharing Sets grant external users access to records based on their relationship to an Account or Contact. If a user’s Contact is linked to an Account, a Sharing Set can grant them access to records tied to that same Account.
One nuance that bit me: not every license behaves the same. Customer Community Plus unlocks the more advanced, role-based sharing that plain Customer Community doesn’t. So “it works fine in my test org” can quietly turn into “it doesn’t work for this license tier.” Confirm the tier before you design the sharing model, not after.
What buyers can see and buy runs on entitlements, not sharing
This is the one that made me feel like I’d skipped a chapter. I had the buyer’s Contact set up, the user enabled, and sharing configured the way I would for a service portal. The buyer logged in. The store was empty.
Product visibility and pricing in a B2B store don’t come from Sharing Sets or OWD. They run through a separate chain that’s specific to Commerce, and every link has to be connected:
- The buyer’s Account has to be set up as a Buyer Account.
- That Buyer Account goes into a Buyer Group.
- The Buyer Group gets an Entitlement Policy (which products this group is allowed to see) and one or more Price Books (what those products cost them).
Wire all of that to the store, and the buyer finally sees a catalog. Salesforce documentation clearly states that the products a buyer can view and the prices they see depend on the price books and entitlement policies assigned to their buyer group. If even a single link is missing, they won’t see anything. Or worse, they might see products without prices, which looks like it’s almost working and leads you to debug the wrong thing.
The mental switch that finally stuck for me: Sharing Sets and OWD control record visibility, the kind of access you already think about in Sales or Service Cloud. Buyer Groups, entitlements, and price books control the shopping experience. Two separate access systems, running side by side, and a buyer needs both to be right.
Get very comfortable asking “where is this configured?”
Here is the key factor that ties the other five elements together. In other clouds, I usually knew where to look. In B2B Commerce, the answer lives in more places than you’d expect: the Experience Cloud site, a flow, a permission set, a Sharing Set, a Contact, an Account, a Buyer Group, occasionally somewhere I hadn’t thought to check yet.
At some point it clicked that knowing where to look was as valuable as knowing what to change. So I started keeping a rough map. Here’s a simplified version of mine:
| What you're trying to change | Where it usually lives |
|---|---|
| Storefront pages, layout, navigation, branding | Experience Builder (the Experience Cloud site) |
| Creating a portal user | Contact record → Enable Customer User |
| What external users can access (records) | External OWD + Sharing Sets |
| What buyers can see and buy (products, pricing) | Buyer Account → Buyer Group → Entitlement Policy + Price Book |
| Login, self-registration, authentication | Experience Cloud site login settings |
| Business logic and automation | Flows (check whether they run in the store context) |
Mistakes to Avoid
- Trying to create the user directly instead of starting from the Contact.
- Assuming internal sharing rules cover external users. Past a certain point, they don’t.
- Building your sharing model in a Customer Community Plus test org, then deploying to plain Customer Community and wondering why access broke.
- Setting up the buyer’s Contact and sharing, then forgetting to configure the Account as a buyer and assign a Buyer Group, so they log in to an empty store.
- Editing an internal Lightning page when the customer is actually looking at an Experience Builder page.
- Forgetting that External OWD has to be at least as restrictive as your internal OWD.
Final Thoughts
If you’re about to start on B2B Commerce, the most useful thing you can do isn’t memorizing features. It’s building your own “where does this live” map, like the table above, and adding a line every time something surprises you. Mine began as three notes on a sticky and grew into the reference I actually trust.
So here’s the practical next step: spin up a Developer org, enable Commerce and Experience Cloud, create a single Contact, and walk it all the way to a working store login with a product the buyer can actually see and price. Doing that full loop once, end to end, will teach you more than any article can. This one is included.
Frequently Asked Questions
Not exactly. “Commerce Cloud” often refers to B2C Commerce (formerly Demandware), a standalone platform. B2B Commerce on the core Lightning platform is Salesforce-native and runs on Experience Cloud.
Start with a Contact linked to an Account, then use the Enable Customer User action on that Contact. Salesforce creates the user record and grants portal access.
External buyers typically use an Experience Cloud license, most often Customer Community Plus, which supports the cart, checkout, and advanced role-based sharing that basic Customer Community doesn’t.
Through Organization-Wide Defaults (and External OWD) as the baseline, plus Sharing Sets that grant access based on the user’s related Account or Contact.
Usually because the buyer’s Account isn’t set up as a buyer and placed in a Buyer Group that has an entitlement policy and price book assigned to the store. Correct record sharing doesn’t make products appear; the entitlement chain controls that.
No. They authenticate through the storefront’s external experience with the access defined for that site, not the internal org that admins and internal users sign into.
Giorgia Piccini
Giorgia Piccini is a Salesforce Administrator with experience working across Sales, Service, and Commerce Cloud. She has hands-on experience with Salesforce configuration, automation, user management, and translating business requirements into practical CRM solutions. She particularly enjoys working with Flows, automation, and complex Salesforce challenges that require creative and thoughtful solutions. Passionate about continuous learning, Giorgia enjoys exploring the Salesforce ecosystem and sharing practical lessons from her experience with other professionals.
