On-Demand Sandboxes

You can create and manage your own sandbox environments as you need them.

An on-demand sandbox is a public-cloud-based sandbox. When you use on-demand sandboxes, you can expand your sandbox usage when required and roll back usage during slow periods.

To access an on-demand sandbox, you must purchase sandbox credits, enable appropriate permissions and users, and configure a client API ID. Then you can use the self-service API to create the sandbox environments yourself. Using the API, you can also control how many on-demand sandboxes you use and how long the on-demand sandboxes are active.

Permissions for creating and managing on-demand sandboxes are integrated with B2C Commerce Account Manager. When you create an on-demand sandbox, you can specify Open Commerce API and WebDav permissions. You can also specify a time-to-live (TTL) value to automatically delete a sandbox after a specified time interval.

When you create an on-demand sandbox, it's empty, but you can use the standard import and export tools to import data.

You can't directly migrate from a POD-based sandbox to an on-demand sandbox. But you can export data and code from a POD sandbox, and then import the data and code into an on-demand sandbox.

The credit system provides flexibility so you can use the credits that you purchase the way you want. For example, depending on your needs, you can keep just a few sandboxes running for an extended period or create many short-term sandboxes.

Users assigned to the Sandbox API User role can control how credits are spent. When managing sandboxes and sandbox credits, keep these considerations in mind:

• When created or started, a sandbox begins consuming uptime in credits per minute. The number of credits a sandbox consumes per minute depends on which resource profile option a sandbox uses. For example, by default, sandboxes use a medium resource profile. A sandbox using the medium resource profile consumes 1 credit per minute or portion of a minute. A sandbox using a large or extra large resource profile consumes uptime credits at a higher rate.
• Stopped sandboxes consume fewer credits per minute. When stopped, regardless of which resource profile they use, all sandboxes consume downtime credits at a rate of 0.3 credits per minute or portion of a minute.
• When you delete a sandbox, it stops consuming credits.
• Sandboxes that are down due to technical issues, do not consume credits.

Because sandboxes consume credits while in a stopped state, make sure to delete sandboxes you don't need. Then create them again when you want to use them.

Stop and restart sandboxes only when you want to retain the exact set of data that you created for the sandbox. To better manage sandboxes in a realm, you can set the sandbox autoScheduled parameter to yes and create an Operation Scheduler to automatically start and stop the sandboxes.

If you need a sandbox repeatedly for the same purpose, consider using APIs to automate creating a sandbox and importing the applicable data and code. Then you can quickly recreate the sandbox environment after it's deleted.

You can easily import Storefront Reference Architecture (SFRA) into a sandbox using Business Manager. It isn’t necessary to keep a sandbox in the stopped state just to maintain an environment that uses SFRA.

When you create an on-demand sandbox, you can configure an optional Time-to-Live (TTL) value that specifies how many hours the sandbox lasts. For example, if the sandbox has a TTL of 24, the sandbox lasts for 24 hours and then is automatically deleted.

The maximum TTL for a sandbox is 2160 hours. A sandbox with a TTL value of 0 or less lasts until it is deleted.

This snippet from the JSON body of a POST/sandboxes API call to create a sandbox sets the TTL value of the sandbox to 100 hours.

After a sandbox is created, you can change its TTL value using a PATCH/sandboxes API call. This snippet from the JSON body of a PATCH/sandboxes{sandboxId} API call updates the TTL to 0, specifying that the sandbox lasts until it is deleted using a DELETE /sandboxes/{sandboxId} call.

In the B2C Commerce Developer Sandbox REST API Swagger UI, the example to create a sandbox with a POST/sandboxes API call uses a TTL value of 24. If you don't change the TTL in the example request body, the sandbox is created with a TTL of 24 hours. To use a different TTL, update the ttl value in the example before clicking Try it out.

Every realm has settings for default TTL and maximum TTL for all sandboxes in the realm. The default TTL for the realm is 24 hours. To change the default TTL for the realm, use a PATCH/realms/{realm}/configuration API call. You can also override the realm default for any sandbox in the realm by setting the TTL for that sandbox to a different value.

The default maximum TTL setting for a realm is 0, indicating that no maximum has been set. You can set a maximum TTL, up to 2160 hours, for all sandboxes in the realm using a PATCH/realms/{realm}/configuration API call. When a default maximum TTL is set for the realm, you get an error if you try to create a sandbox in the realm with a TTL higher than the maximum.

If you need a sandbox for a short-term use, specify a TTL that covers only the time required. If your project has an uncertain end date, configure the TTL as 0 or less so that the sandbox lasts until you delete it. As an alternative, use a large TTL, such as 2100 hours, but then manually delete the sandbox when the project is completed.

In the B2C Commerce Developer Sandbox REST API Swagger UI, the example to create a sandbox with a POST/sandboxes API call uses a TTL value of 24. If you use the Try it out feature to create a sandbox from the Swagger UI and don't change the TTL in the example request body, the sandbox has a TTL of 24 hours. To use a different TTL, update the ttl value in the Example before clicking Try it out.

To keep sandbox environments stable and reliable, we reserved two fixed maintenance windows for deployments and maintenance operations that can cause short interruption of operation to On-Demand Sandboxes.

• Tuesday or Thursday, 5:00 AM to 7:00 AM CET - B2C Commerce Preview and Preview Update releases.
• Thursday, 7:00 AM to 9:00 AM CET - CCDX Sandbox infrastructure and platform updates.

We don't use the maintenance window every week. When we plan to make updates during the maintenance window, we post advanced notification in the Salesforce Trust Center.

On-demand sandbox storage size can vary depending on the resource profile that the sandbox uses.

By default, each on-demand sandbox has 10 GB of storage and an extra 10 GB of storage available on the realm that all on-demand sandboxes can share. However, you can assign one of three discrete profiles to each on-demand sandbox according to your performance needs. This table describes the storage settings for each resource profile.

Log messages for on-demand sandboxes are collected in a dedicated log center.

You can view the logs for the realms that you have access to based on your role.

We've prepared some resources to help you optimize your experience with On-Demand Sandboxes.

• On-Demand Sandboxes Webinar Slide Deck: Use this webinar slide deck to learn more about Salesforce B2C Commerce On-Demand Sandboxes.
• B2C Commerce On-Demand Sandboxes FAQ: Use this FAQ to get answers to common questions about On-Demand Sandboxes.
• B2C Commerce On-Demand Sandbox Demo Videos: Watch On-Demand Sandbox REST API Swagger UI and On-Demand Sandbox Salesforce Commerce Cloud Command Line Interface (SFCC-CI) demos.
• B2C Commerce On-Demand Sandbox Credits Calculator: This Microsoft Excel spreadsheet provides an example for calculating On-Demand Sandbox credits. You can download the file, make a copy, and use it for your own calculations.