Audience: B2C Commerce partners
This document outlines the requirements, benefits, and pricing for obtaining Partner On-Demand Sandboxes for B2C Commerce ISV & B2C Commerce Consulting Partners.
B2C Commerce On-Demand Sandboxes are a flexible way to address your sandbox needs with improved performance, ability to be acquired quickly, usage-based pricing, and can grow or shrink as your needs change.
Partners can request On-Demand Sandboxes by following the instructions in this article: Partner On-Demand Sandboxes - How to get one. On-Demand Sandboxes offer greater flexibility, such as:
Partners must first join the AppExchange Partner Program under the “B2C Commerce” Partner Category and accept the Salesforce Partner Program Agreement and the AppExchange Partner Program Policies. Afterwards, Partners must have either (a) executed an Order Form in connection with the On-Demand Sandboxes or (b) enrolled in the Salesforce B2C Commerce Consulting Partner Program and have been pre-approved to become a B2C Commerce Consulting partner are eligible to use On-Demand Sandboxes. Partners must maintain good standing at all times.
The Trial Sandbox/Environment is created for B2C Commerce ISV prospects to use up to 90 days for training and development purposes. It is designed for prospects who want to gain exposure to the B2C Commerce environment while waiting for the onboarding process to be completed and/or deciding whether they will formally join the B2C Commerce Partner Program. Request your Trial from this link.
Need to export data from a Trial Sandbox and import it to a dedicated On-Demand Sandbox? Trial sandboxes do not convert into On-Demand Sandboxes, so if you’d like to use what you have built in the trial version, you'll need to export the data from the trial sandbox into the On-Demand sandbox. Please review the information about: Site Import/Export in B2C Commerce for detailed instructions on how to do so after you have successfully requested an On-Demand Sandbox.
No. Due to program changes, additional credit blocks are no longer available for purchase. However to ensure fair pricing, we’ve lowered the overage rate to match the additional credit block per credit rate ($.0020 USD per credit).
Enablement materials are listed below:
On-Demand Sandboxes are set up on a usage-based model. Partners are entitled to free credits based on their partner program affiliation. This gives partners complete control over how many sandboxes they use and when they use them. They can use their credits to keep just a few sandboxes running over an extended time, or they could run many sandboxes over short periods of time (i.e. in a Continuous Integration (CI) use case).
Credits are a means to consume time on the On-Demand Sandboxes service. For GA there are two sandbox modes that consume credits: uptime and downtime. When a sandbox is created or started it is consuming uptime. When it is stopped it is consuming downtime. Only when a sandbox is removed does it stop consuming credits.
A non-stop running sandbox within a one-month period is equivalent to 50,000 credits.
Uptime means a sandbox is consuming CPU and memory. When a sandbox is created or started it is consuming uptime. When it is stopped, but not removed, it is consuming downtime. When the sandbox is removed it no longer consumes anything. Using the API users can create, start, stop, and remove sandboxes:
You can also use the Control Center to manage your ODS instance.
Yes. Sandboxes that are consuming uptime will consume 1 credit for medium profiles, 2 credits for large profiles, and 4 credits for xlarge profiles for each minute (or portion thereof) that the sandbox is in uptime. Sandboxes that are consuming downtime will consume 0.3 credits for each minute (or portion thereof) that the sandbox is in downtime.
As a B2C Commerce ISV Partner for example, you’ll receive 600k credits free of charge on an annual basis, so if you want to have a single sandbox running non-stop for a year, you will automatically go into overage after you have used up your allotted standard credit amount which will be calculated on the first day of each month and invoiced accordingly.
With the flexibility of the new sandboxes they can be used for various short-lived tasks (example: use them in a Continuous Integration process) and any number of them can be created. As these capabilities are used the simple “x number of sandboxes per year” calculation may be too much or too little. To help with this we have created a spreadsheet that can be copied and used to calculate credits required based on different usage scenarios.
If you are a B2C Commerce ISV Partner, you are entitled to create up to 5 Sandboxes. If you are a B2C Commerce Consulting Partner, you can create up to 50 Sandboxes. Each sandbox will consume credits based on uptime or downtime at the rates described above.
Note: There are some practical upper limits. These are to prevent runaway processes or gross misuse of the system.
Partners are able to see sandbox data (what sandboxes currently exist, who created them, how long they have existed and how many minutes they have consumed) via the Sandbox API. For example, the GET /realms/usage API can be used to retrieve the full details for usage in a realm. It shows the minutes of uptime and downtime that have been consumed over a specified time period.
Yes, you can use B2C Commerce Control Center to view your on-demand sandbox usage as explained in this article.
No, credits need to be used by the order end date that is listed on the sandbox order form you signed, however Partner Credits reset annually so the credit count for B2C Commerce Partners will reset at renewal.
No, On-Demand Sandboxes auto-renew per the Main Services Agreement terms so once the initial request is completed, it will automatically renew annually which means credits will auto-reset at that time unless a request is submitted internally to deprovision or terminate the partnership.
Yes, there are overage charges. Overage is calculated on the first day of the month and an invoice will be sent to the partner.
Use the following APIs to stop or remove sandboxes when you don't need them so that it consumes minimal or no resources.
No. The sandboxes continue to function and continue to consume credits. Partners are billed for overage on the credits used (see above).
Partners must submit a ticket in the Partner Community to request access. Instructions can be found here: On-Demand Sandbox - How to get one.
On-Demand Sandboxes cannot currently import data from the staging environment as they run on a different infrastructure and are not connected at all to the legacy POD environments. All data operations rely on the standard import/export processes. You can get the data exported first from staging, cleaned up, then transfer the file to the On-Demand Sandboxes and import it there.
Yes. On-Demand Sandbox provides 3 different resource profiles. The resource profile must be chosen when the sandbox was created. See the On-Demand Sandbox Storage documentation for details.
Similar to current POD sandboxes, the On-Demand Sandboxes do not allow the scheduling of jobs. Jobs can be run manually, or can be run using the SFCC-CI tool in a scripted form.
Yes. DIS support is available and can be used with On-Demand Sandboxes.
Einstein AI & Recommendation features are not available in the existing ODS instances by default. Please contact us if your use case(s) needs these features.
Yes. Page Designer is available for use in the new sandboxes.
A CDN is not currently available for the On-Demand Sandboxes. This means that using things such as SEO routing and data caching are not available for these new sandboxes.
You can stop a sandbox (using the sandbox:stop API) which will stop the sandbox from using CPU and memory and will switch to “downtime” consumption. The sandbox can be restarted and will have all of its previous data. However, if a sandbox is removed (using the sandbox:remove API) then all data is deleted.
No, ODS instances aren't designed to support load testing, and we are not recommending to do load testing on them.
Alias support (CNAME configuration) is not currently available for the On-Demand Sandboxes. Allowing for CNAME configuration and hence using custom hostnames is something on the roadmap for after the GA release.
No. When On-Demand Sandboxes are created, they are empty. However, you can use all of the same import/export tools to import a predefined data set and upload it to the sandbox.
All interactions with the On-Demand Sandboxes are done through either an API call or via the community based SFCC-CI command line tool (see the Question: What is the SFCC-CI Command Line Tool?). The full documentation for the API and methods that can be used can be found at this link.
All authentication to an On-Demand Sandbox is done with Account Manager users. This actually makes the management of and access to On-Demand Sandboxes much easier to use, especially with frequent removal and creation of new sandboxes.
Any user that is going to use the On-Demand Sandbox APIs or use the SFCC-CI tool for administering the On-Demand Sandboxes will need the Sandbox API User role added to their Account Manager user profile and applied to the sandbox scope in their realm.
Developer access to any sandbox ( On-Demand Sandboxes) also requires the roles for Business Manager Administrator (for access to developer options in Business Manager) and LogCenter User (for access to see environment log files) to be added and applied to the sandbox scope in their realm.
In order to assign these roles, do the following:
All API usage within B2C Commerce requires a Client ID value to indicate the application that is using the API. Since On-Demand Sandboxes are administered using APIs you will need a client ID to use them. Many current developers will already have one of these values for their organization. However, if the user doesn't have a Client ID, the organization’s administrator can create one using the Account Manager. For automation usage, users will need the Client ID as well as the Client Secret for authentication.
For full details on Client IDs, including how to obtain one, refer to the Configure an API Client ID documentation.
Not at this time. For the GA release all administration of the new sandboxes will need to be done with the APIs and/or the SFCC-CI tool.
Yes. On-Demand Sandboxes can be managed using the Control Center as explained in this article. All administration of these new sandboxes needs to be done with the APIs and/or the SFCC-CI tool.
No. The sandbox:remove command is a data destroying activity. Once executed the sandbox system will proceed with removing the environment and all of its data in accordance with Salesforce data privacy and trust rules.
SFCC-CI is a community-based project that the Commerce Cloud Customer Success Group has created on GitHub. This tool is built on top of the OCAPI and Sandbox APIs and provides a command line interface (CLI) for interacting with Commerce Cloud instances from the command line / shell of various operating systems in order to facilitate Continuous Integration practices using Commerce Cloud. Interacting with the On-Demand Sandboxes is a part of what this tool can do. Using this tool for On-Demand Sandbox creation still requires the user to have the Sandbox API User role that is mentioned in the paragraphs above.
For full details, please see the SFCC-CI GitHub repository and its Readme file.
For issues or general/technical questions related to On-Demand Sandboxes, please post in the Partner On-Demand Sandbox Community Group.
000393797

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.