Configure On-Demand Sandbox Roles and Settings

Learning Objectives

After completing this unit, you’ll be able to:

• Describe the difference between on-demand sandbox roles.
  
• Explain the on-demand sandbox credit system.
  
• Explain the purpose of the ODS time-to-live property.
  
• Summarize the requirements for an API client and realm ID.
  

Set Up User Roles for On-Demand Sandboxes

To create a Commerce for B2C ODS by using the Commerce for B2C Developer Sandbox REST API, you need specific roles and permissions within the Salesforce ecosystem. These roles and permissions ensure secure and authorized access to the necessary APIs and resources. Here are the key requirements.

Your Commerce for B2C admin uses Account Manager to assign roles with a scope filter. The scope filter settings include:

• All sandboxes: The filter grants access to all sandboxes, realm-level operations, and sandbox creation or deletion.
  
• Individual sandboxes: The filter grants access only to those specific sandboxes and their APIs. The individual sandbox filter doesn’t grant realm-level access or the ability to create new sandboxes.
  

To learn more about how to assign roles to new or existing users, check out Create a User Account in B2C Commerce or Edit a User Account in B2C Commerce.

Manage Costs with On-Demend Sandbox Credits

On-demand sandboxes operate on a credit-based system. Organizations purchase sandbox credits to enable the creation and management of the sandboxes. 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. 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. The resource profile options include:

• medium: (Default) 1 CPU, 10-GB storage. Use this level for standard development.
  
• large: 2 CPUs, 20-GB storage. Use this level for larger datasets.
  
• xlarge or xxlarge: Up to 8 CPUs and 100-GB storage. Use these levels for performance-intensive tasks.
  

Developers require environments that mirror production specifications to ensure code compatibility and performance. The correct resource profile helps the sandbox handle the workload, such as heavy automated testing, or simple feature updates without wasting credits.

Users with the Sandbox API User role can control the spending of credits. When managing sandboxes and sandbox credits, keep these considerations in mind.

• By default, sandboxes use a medium resource profile. A sandbox with the medium resource profile consumes 1 credit per minute or portion of a minute. A sandbox with a large or extralarge 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, don’t consume credits.
  

Sandboxes consume credits even when stopped. Delete the ones you don’t need and create them when you’re ready to use them again. Only stop and restart a sandbox when you want to keep the exact data that you set up in it.

Control Credits with an Operation Scheduler

Sandboxes that run 24/7 drain credits unnecessarily. To manage sandboxes in a realm efficiently, you can create an operation scheduler to start and stop the sandboxes so that they only run during working hours. In the B2C Commerce Developer Sandbox REST API Swagger UI, the example to create an operation scheduler with a PATCH/realms/{realm}/configuration sandbox API call specifies a schedule to start and stop the sandbox every weekday.

{
  "emails": [
    "email1@example.com",
    "email2@example.com"
  ],
  "sandbox": {
    "sandboxTTL": {
      "maximum": 240,
      "defaultValue": 24
    },
    "startScheduler": {
      "weekdays": [
        "MONDAY",
        "TUESDAY",
        "WEDNESDAY",
        "THURSDAY",
        "FRIDAY"
      ],
      "time": "08:00:00+03:00"
    },
    "stopScheduler": {
      "weekdays": [
        "MONDAY",
        "TUESDAY",
        "WEDNESDAY",
        "THURSDAY",
        "FRIDAY"
      ],
      "time": "19:00:00Z"
    }
  }
}

The automated control of start and stop times helps you manage credit consumptions so your sandbox environments remain available for critical development and testing activities without exceeding allocated credits.

Manage ODS Life with Time to Live

When you create an on-demand sandbox, you can use the optional time-to-live (TTL) value to specify exactly how many hours the sandbox lasts before the system automatically deletes it.

For example, if you set a TTL of 24, your sandbox lasts for 24 hours. After that timer runs out, the system deletes the sandbox and all of its data.

Set TTL for the Realm

The realm configuration establishes the default and maximum TTL for all sandboxes within it. You can adjust the 24-hour default or the maximum limit (up to 2,160 hours) using a PATCH/realms/{realm}/configuration API call. Setting the maximum TTL to 0 allows sandboxes to remain active until manually deleted.

Configure TTL for Your Sandbox

To customize a specific environment, set an individual TTL that overrides the realm default. Individual values must not exceed the realm's maximum limit. Setting a sandbox TTL to 0 keeps that specific instance active indefinitely, provided it complies with the realm-level maximum.

TTL Best Practices

Select a TTL strategy that fits your project needs.

• Short-term: For a quick task, specify a TTL that covers only the time required.
  
• Uncertain timeline: For open ended projects, configure the TTL as 0 so it lasts until you delete it.
  
• Safety net: Alternatively, use a large TTL, like 2,100 hours, and manually delete the sandbox when you finish to save credits.
  

Add an API Client ID

The Commerce for B2C Developer Sandbox REST API authentication process requires an API client ID. The client ID helps to:

• Identify the client application making the request.
  
• Make sure that the request is coming from an authorized source.
  
• Track and manage API usage.
  

If you plan to use scripts to automate API calls, the API Client ID requires the password for authentication.

To add an API client ID for the Sandbox API, use the Add an API Client in B2C Commerce procedure. Users with the Account Administrator or API Administrator roles can manage API client IDs.

Get Your Realm ID

A realm contains your Primary Instance Group (PIG) and Secondary Instance Group (SIG). The SIG contains the sandboxes. Each realm has a unique four-character ID that you can get from your account executive (AE) or customer success manager (CSM).

Next Steps

In this unit, you explored how to assign user roles. You also learned about sandbox credits and how to manage credits. Next, you discover how to use the Commerce for B2C Developer Sandbox REST API Swagger UI to create a Commerce for B2C on-demand sandbox.

Resources

• Salesforce Help: Account Manager for B2C Commerce
• GitHub: Agentforce Commerce (GitHub credentials required)
• Agentforce Commerce: Account Manager (Account Manager credentials required)