No change reaches shoppers without review. The Content Sandbox is the platform’s answer to the risk of live edits — every content change, pricing update, tax configuration, and payment rule can be staged, previewed by stakeholders, approved through a configurable workflow, and published on a schedule. If something goes wrong after publishing, it can be rolled back instantly.
Changes in a sandbox have no effect on the live store until explicitly published.
Scope#
Not everything goes through a sandbox — the rule is based on risk.
| Category | Sandboxed? |
|---|---|
| Products, categories, pages, banners, promotional copy | Always |
| Pricing rules (discounts, tiered, promotional) | Always |
| Tax configuration (rates, zones, exemptions) | Always |
| Payment methods (gateways, routing rules) | Always |
| Shipping configuration (zones, rates, carrier rules) | Always |
| All other store settings | Applied immediately — no sandbox |
Publishing Modes#
Three modes are available and can coexist on the same store:
Draft → Approve → Live#
The standard approval workflow. A sandbox is created and edited, then submitted for approval. A user with the publish permission reviews it and either approves (triggering publish) or rejects it. No changes go live without an explicit approval action.
Concurrent Sandboxes#
Multiple sandboxes can exist simultaneously on the same store. Each is an independent change set that can be promoted on its own schedule. Useful for parallel workstreams — a pricing update and a content refresh can be staged and published independently.
Scheduled Publishing#
A sandbox can be set to auto-publish at a specified date and time. No manual approval is required at publish time — the schedule acts as the publication trigger. The sandbox must be approved before the schedule is set.
Access Control#
The approval chain is configurable per store. Each store defines which roles can create sandboxes, which can approve them, and which can publish or schedule them. There is no platform-wide fixed role mapping for sandbox actions.
Conflict Detection#
When two concurrent sandboxes both modify the same content item or setting, the platform detects the overlap at publish time and blocks the second publish. The conflict must be resolved manually — the conflicting sandbox cannot be published until the overlapping changes are reconciled.
Last-write-wins is explicitly not used, as it risks silent data loss.
Preview#
Every sandbox has a shareable preview URL that renders the full storefront with the sandbox changes applied. The URL can be shared with stakeholders who do not require admin access to the store. The preview reflects the sandbox state at the time the link is accessed — it updates as the sandbox is edited.
Rollback#
Rollback is all-or-nothing at the sandbox level. When a published sandbox is rolled back, all of its changes are reverted together as a single unit. Field-level or partial rollback is not supported — if selective reversion is needed, a new sandbox with the corrective changes is the correct approach.
Audit Log#
Every sandbox action is recorded in an immutable audit log:
| Action | Recorded data |
|---|---|
| Create | User, timestamp, sandbox name |
| Edit | User, timestamp, fields changed |
| Submit for approval | User, timestamp |
| Approve / Reject | User, timestamp, optional note |
| Publish | User, timestamp, publishing mode |
| Schedule set | User, timestamp, scheduled datetime |
| Rollback | User, timestamp, reason |