How to Share One Salesforce B2C Commerce Sandbox Across Multiple Developers

Quick answer: Salesforce doesn’t recommend multiple developers working in a single sandbox, and that guidance hasn’t changed. What has changed is the reason it matters less than it used to: On-Demand Sandboxes (ODS) now let every developer spin up a personal, disposable instance in minutes through Business Manager, Account Manager Control Center, or the new B2C Commerce CLI. A shared sandbox with one site per developer is still possible and still occasionally necessary, for tight sandbox-credit budgets, for QA environments, or for teams testing multi-site configurations, but it’s a fallback, not the default.

This piece updates our earlier walkthrough of that fallback approach, and folds in what’s actually changed on the platform: the rename from Salesforce Commerce Cloud to B2C Commerce, the arrival of On-Demand Sandboxes and sandbox cloning, and a new generation of tooling (B2C CLI, Agent Skills, and IDE extensions) that’s already replacing sgmf-scripts and the community Prophet Debugger for a lot of teams.

Salesforce Commerce Cloud Is Now B2C Commerce: What That Means for Sandboxes

The product most developers still call “SFCC” is now branded B2C Commerce in Salesforce’s own documentation and developer center. The rebrand isn’t cosmetic where sandboxes are concerned: Salesforce has been steadily moving sandbox provisioning off manual support tickets and onto self-service APIs, and 2026 added on-demand sandbox cloning, letting a team duplicate an existing sandbox- code, catalog, and configuration included- in minutes rather than rebuilding it by hand, a capability introduced alongside a new open-source B2C Commerce CLI and SDK built to handle code deployment, sandbox provisioning, CDN configuration, and Managed Runtime bundles from one place. Salesforce Developers

That single change removes most of the original reason teams reached for a shared sandbox in the first place: sandbox scarcity.

Should Multiple Developers Still Share One Sandbox?

Salesforce’s position is unchanged: one sandbox per developer is the supported, low-friction pattern, because concurrent deployments and job runs from different people on the same instance still produce the same conflicts they always did, overwritten code versions, clashing catalog jobs, and confusing Business Manager states. On-Demand Sandboxes exist specifically to make “one developer, one sandbox” affordable and fast rather than a resourcing problem.

That said, a shared sandbox with a dedicated site per developer remains a legitimate pattern in a few situations:

• Your organization has a fixed sandbox-credit budget and can’t provision one ODS per person.
• You’re deliberately testing a multi-site Business Manager configuration, the same setup a single brand uses to run separate storefronts per region on one production realm.
• You need a long-lived, shared integration or QA environment rather than several short-lived personal ones.

If none of those apply to your team, skip to the ODS section below, it’s the faster path in 2026.

Give Every Developer an On-Demand Sandbox (ODS): The Default Path Now

An On-Demand Sandbox is a self-service, public-cloud instance that a developer can create, resize, and delete without opening a support ticket, letting teams scale sandbox usage up during a project and back down during quiet periods. Each ODS lives inside your realm’s Secondary Instance Group (SIG), your realm’s four-character ID comes from your Account Executive or Customer Success Manager if you don’t already have it, and managing sandboxes at scale requires the Sandbox API User role, scoped to that realm, assigned through Account Manager. On-Demand Sandboxes +2

Three Ways to Create a Sandbox

1. Business Manager / Account Manager Control Center — log in to Control Center, select your realm, and click Create on-demand sandbox. You’ll set a time-to-live (0 for no expiry, 24 or 48 hours for short-lived work) and a resource tier: Medium, Large, X-Large, or XX-Large, with larger tiers consuming more sandbox credits. salesforce
2. Sandbox API directly — call POST /sandboxes with your realm ID and an optional TTL of up to 2,160 hours (90 days) if you’d rather script the request than click through a UI. salesforce
3. B2C Commerce CLI — the newer route. After installing the CLI (npm install -g @salesforce/b2c-cli) and running b2c setup to store your Account Manager credentials, sandbox creation, start, stop, and delete all become terminal commands rather than console clicks, and the same commands work from a CI pipeline or a coding agent. Salesforce Developers

A freshly created ODS is empty, you still import data into it using the same Site Import & Export tooling covered below.

When You Genuinely Need One Shared Sandbox With a Site per Developer

If a shared instance is still the right call for your team, the underlying pattern hasn’t changed: mirror what a single brand does in production, where one instance hosts a separate site per region or country. Each developer gets their own site ID, their own cartridge stack, and their own storefront view, all inside one shared sandbox.

Step 1: Export a Baseline From an Existing Sandbox

In Business Manager: Administration → Site Development → Site Import & Export.

• Under Data Units to Export, select the site(s) and any supporting data (catalogs, customer lists, price books) you want to carry over, name the archive, and click Export.
• The job appears with a start time and status; wait for it to complete.
• Under Upload Archive, click the generated .zip and download it locally.

Note that code uploads and imports work differently across environment types: uploads to an active code version are only permitted on Sandbox, Development, and Staging instances, Production rejects WebDAV code uploads straight into the live version. That distinction matters if your “shared sandbox” workflow ever gets confused with a staging environment further down the pipeline. salesforce

Step 2: Rename the Site and Import It Into the Shared Sandbox

Unzip the archive locally and edit the site’s XML metadata, the folder name, site ID, and display title all need to change to something unique per developer (site-devalice, site-devbob, and so on). Re-zip the parent folder, then repeat the same Site Development → Site Import & Export path on the target sandbox: upload the archive, select it, and click Import. Once the job completes, the new site shows up in the site picker and its storefront becomes viewable.

Step 3: Set Up Your Own Custom Cartridge Layer

The scaffolding command most SFRA teams have used for years still works. sgmf-scripts is a maintained npm package for generating overlay cartridges, compiling assets, and uploading code, and Salesforce’s own Trailhead content still walks through it as the standard way to create an overlay cartridge without touching app_storefront_base directly: salesforcenpmjs

bash

mkdir app_custom_sitename
cd app_custom_sitename
npm install -g sgmf-scripts
sgmf-scripts --createCartridge app_custom_sitename
npm install

Then compile your assets as usual:

bash

npm run compile:scss
npm run compile:js
npm run compile:fonts

If your project has already migrated to the new B2C Developer Tooling, the equivalent scaffolding and code-push operations run through the B2C CLI instead, with the added benefit of Agent Skills that let a coding assistant drive the same commands. Both approaches are valid; which one you use depends on what your project has already standardized on. Salesforce Developers

Step 4: Point the Cartridge Path at Your Own Site

In Business Manager, go to Administration → Sites → Manage Sites, select your site, and under cartridge path settings, order your custom cartridge ahead of the base cartridge (for example app_custom_sitename:app_storefront_base). Apply the change so the sandbox resolves your overlay first.

Step 5: Push Code With Current Tooling

This is the part of the old workflow most in need of an update. The community-maintained Prophet Debugger extension for VS Code is still around and still functions against the Script Debugger API, but Salesforce now ships its own supported alternatives:

• B2C DX VS Code Extension — an official extension built on the same CLI and SDK used everywhere else in the B2C Developer Tooling project, so cartridge upload and debugging stay consistent with your terminal workflow.
• Agentforce Commerce Vibes — a VS Code extension for building, administering, and debugging B2C storefront projects with AI-assisted chat and agent skills layered on top of the Agentic B2C Developer Toolkit. Salesforce Developers

Whichever tool you pick, the upload behavior is the same one developers have relied on for years: point it at your sandbox, upload your cartridge stack, and choose to keep existing code on the instance rather than overwrite a teammate’s version when prompted.

Step 6: Configure Your Instance File for the Shared Sandbox

The connection file most tools read is still dw.json, though its shape has broadened. Username/password still works, but current tooling supports OAuth client credentials as an alternative, particularly for CI pipelines and code-activation permissions:

json

{
  "hostname": "your-sandbox-hostname.sandbox.us01.dx.commercecloud.salesforce.com",
  "username": "[email protected]",
  "password": "your-account-manager-password",
  "client-id": "your-api-client-id",
  "client-secret": "your-api-client-secret",
  "code-version": "your-current-code-version"
}

Give each developer their own code-version string if you’re all pushing to the same shared sandbox, it’s the single easiest way to avoid overwriting a colleague’s in-progress build.

Common Pitfalls on a Shared Sandbox

• One code version, many developers. If everyone deploys to the same active version, the last upload wins. Assign a version per person, or per feature branch, and activate deliberately.
• Job collisions. Import/export and catalog jobs queue at the instance level. A long-running job kicked off by one developer can block or slow another’s.
• Site ID collisions after cloning. Forgetting to rename every reference inside the exported XML, not just the folder name is the most common reason a re-imported site fails to appear correctly.
• Credential sprawl. Shared Account Manager logins are harder to audit than individual ones; where possible, give each developer their own Account Manager identity even on a shared sandbox.

Frequently Asked Questions

Cloud Odyssey’s Take

We still tell clients the same thing Salesforce’s documentation says: don’t build a habit around a shared sandbox if you can avoid it. On-Demand Sandboxes have made “one developer, one environment” cheap enough that the old multi-site-per-sandbox workaround has moved from default practice to a targeted fallback, useful for credit-constrained teams or genuine multi-site QA, not a workflow you want to standardize on.

Where we do still see the shared-sandbox pattern earn its place is in agencies and partner teams juggling several client sandboxes with a tight credit allocation, or in QA environments meant to outlive any single developer’s sprint. In those cases, the discipline that matters most isn’t the Business Manager configuration, it’s getting code versioning and cartridge-path ownership agreed on before the second developer ever touches the instance. That single conversation prevents most of the conflicts teams associate with sandbox sharing in the first place.

If your team is weighing On-Demand Sandboxes against a shared multi-site setup, or migrating from sgmf-scripts and Prophet Debugger to the newer B2C Commerce CLI tooling, that’s exactly the kind of B2C Commerce environment planning we help clients work through.