Sandboxes, Workflow, and Change Management

A sandbox is a view of your eCommerce catalog. That view combines everything that has been published plus any changes made in the sandbox.

More specifically and technically, sandboxes manage the process of getting your products from idea to store. Sandboxes are:

• Virtual spaces where you can create, configure, review, and test changes to products, including plans, bundles, and fees, other catalog items, such as notifications and offers, and content items
• A useful way to segregate and coordinate your campaigns
• Essential for reviewing and testing new and changed catalog items before they get to the store

Sandboxes track the status of and allow you to view the changes that you and other users make within the eCommerce section of Service Design Center. The tracking includes changes in the following areas:

• Catalog, including categories, products (including fees and product bundles), upgrade/downgrade groups, price lists, and offers
• Content, including pages and content items
• Design, including themes

When you are working within a sandbox, which you can tell by seeing the sandbox selection drop-down at the top of the page, then every change you make is done within the context of that sandbox. Before adding, making changes to, or deleting a plan, fee, or other product, you should make sure you're in the correct sandbox because you cannot move changes between sandboxes.

Sandboxes are especially important for testing your products. When you assign that customer to a sandbox by changing a customer account to a Test account, that account's devices can see the changes to products that are in the assigned sandbox. The sandbox changes are not yet deployed, but the customer assignment to the sandbox allows account devices to get and test those changes. See Testing for more details.

When you sign in, you return to the same sandbox view you were in when you signed out. 

Sandbox Views

Catalog, content, and design items are viewed through a sandbox. The view contains:

• All items that currently exist. All users see these, and this is the baseline to which changes are applied when the changes are approved.
• All changes that have been promoted. These changes include additions, edits, and deletions. All users see these.
• All changes you have made that have not been promoted. Only you see these. 

The result is that in a sandbox, you can view a combination of the items available to your customers and items you're developing.

There are two types of sandbox views, your default sandbox view and custom sandbox views.

"Your" Sandbox View

Until someone creates more, there is only one sandbox, the Default sandbox. In appearance, it seems to be "yours," in that when you're on a page that is filtered through a sandbox view, it will say "[YourUserName]'s Sandbox." But unlike other sandboxes, when you're in the Default sandbox, the word "Default" is omitted.

Like with any other sandbox, any changes you make in the Default (or "your") sandbox are not viewable by other users until you promote them. If you make a change and promote it, other users will see the changes in "their" sandboxes, their view/version of the Default sandbox. Even though each users appears to have their "own" sandbox, it's just their view of the Default sandbox.

Custom Sandbox Views

Custom sandbox views are explicitly created by Service Design Center users. When you create a custom sandbox, it inherits everything that is deployed at the time of its creation and it can be seen by all users. All users can make changes in that sandbox. All promoted changes made in that sandbox are contained within that sandbox and can be seen by any users in that sandbox view.

For example, you create a sandbox called "Winter Sale." When you go to that sandbox, you'll see "[YourUserName]'s Winter Sale Sandbox" at the top of the page. When you go back to the Default sandbox, you'll see just "[YourUserName]'s Sandbox."

Changes made in a custom sandbox are kept separate from changes made in any other sandbox, including the default sandbox and other sandboxes. This allows you to view and test the entire catalog as it would be if the changes in the custom sandbox were published. This allows you to test and vet campaigns, putting the ideas and changes for one campaign in one custom sandbox.

Deploying changes in a custom sandbox also updates the catalog view in the default sandbox.

Sandbox Naming

Because sandboxes are containers for sets of changes, the names you give sandboxes can help you keep track of those changes if you make the names meaningful. And because a sandbox name can contain up to 255 characters, there's no need to be cryptic in your naming.

Meaningful names can help everyone on your team understand your intent. For example, let's say you want to create a special promotion for soccer fans for the 2018 World Cup. The easiest, simplest name for the sandbox that will contain everything related to the promotion might be "2018 World Cup Promotional Plans." In other words, don't use cryptic code names.

On the other hand, just because you have 255 characters doesn't mean you should always use all of them. The drop-down list where you choose you sandbox view shows you only about the first 30 characters of the sandbox names, so if you don't differentiate enough between your sandbox names within those first 30 characters, it could be hard to choose the right one sometimes. Make sure the beginning if your sandbox names are clear enough to be able to select the correct one, then use the remaining characters to add useful detail.

The nature of sandboxes as views allows them to be reused. For example, let's say you have an end-of-year sale every year. You could create a sandbox titled "End of Year Sale," and as the sale time approaches, the changes you make for your products for that event would appear in that sandbox view as changes until they are promoted and deployed. Once the sale ends, the "End of Year Sale" sandbox view would be the same as the production store view because there are no mare changes in that sandbox. So that sandbox view could simply "wait" for you to start planning your next and-of-year event, and you could reuse that sandbox each year. 

Using Sandboxes for Testing

Testing changes as they are being developed is one of the uses of sandboxes. You can assign customers (accounts) to sandboxes. When you do, the devices that belong to those accounts can view the promoted changes in the sandbox, which are merged with items live in the store. Once the changes are provisioned, the devices can get and use the products so you can make sure the products work as expected.

Workflow and Change Management

The eCommerce section of Service Design Center provides a structured environment in which to manage everything about what you offer and make available to your customers. That environment centers around a draft-promote-approve-deploy workflow that is used for every change you make. And just about everything you do within the eCommerce section of Service Design Center is considered a change, including adding items, making edits to items, and deleting items. 

Remember that all changes are constrained to a sandbox, which means that the workflow occurs within the same sandbox. In other words, actions within one sandbox do not affect any others. 

Understanding the Workflow

Every change you make when in a sandbox view must go through the draft-promote-approve-deploy workflow. Each step in the workflow is a stage that each change must go through. 

Draft Stage

Changes in draft stage are visible only to the user who made them. These changes are visible in 2 places:

• Where you made the change. For example, on the Categories > Products or Content > Media Assets pages. Changes on those pages are identified by a different colored text and by a pencil icon in the right column.
• On the Site Updates > My Change page. All your changes are listed in the My changes to... sections, each section representing one sandbox. 

When you are ready to move a change to the next stage, you promote the change. 

Promoted Stage

Changes in promoted stage are visible to all users. Changes in promoted stage are also visible by test customer accounts assigned to the sandbox, which is how you test the changes. These changes are visible in up to 3 places:

• Where you made the change. For example, on the Categories > Products or Content > Media Assets pages. Changes on those pages are identified by a different colored text and by a pencil icon in the right column. (Here, changes look the same whether in draft or promoted stage.)
• On the Site Updates > My Change page. All your changes are listed in the Pending Approval section.
• If you have permission to view the page, on the Site Updates > Approvals page. All promoted items from all users are listed in the Items pending action for... section.

Approved Stage

Because approval and deployment are a combined action, there's not a formal "approved" stage. However, changes can be approved and not (yet) deployed (because deployment was set for a future date), and changes in that state, which could be considered just "approved," can be unscheduled.

You can view approved and not (yet) deployed changes on the Site Updates > Deployments page in the Pending Deployments section. 

Deployed Stage

The deployed stage is when changes become available to customers. Once a set of approved changes is deployed, it is viewable on the Site Updates > Deployments page in the Past Deployments section. 

Understanding Change Management

When multiple users make changes to the same item, Service Design Center does its best to resolve those changes automatically when the changes are moved between stages. The default principle is that the most recent change "wins," that is, if multiple users make changes to the same part of an item, and if those changes are promoted at the same time, the most recent change takes precedence. A simple example:

• Product A has a price of $5.00.
• User "A" changes the price to $10.00 and promotes the change.
• User "B" sees the change that user A made and thinks that it's too much for the product, so changes the price to $8.00 and promotes that change. 
• The "store manager" user approves both changes and schedules the change to be applied to the product in the store on the first day of the next month. The price of product A will be $8.00.

Sometimes, Service Design Center cannot resolve multiple changes to the same item. If it cannot, it will prompt you to sync your sandbox. Syncing a sandbox means refreshing your view with changes made by all other users. 

Understanding State Symbols

As you move changes through the draft-promote-approve-deploy process, you may see several symbols of change state. Some of these symbols indicate progress through the process, and others indicate error state. 

Location	Symbol	Text	Meaning
Any sandbox view		orange	Any change. Appears next to any item that has been changed, but not approved.
My Changes page		black or red	Rejection or retrieval of a change. If a change was rejected, the approver can add a message to the rejection. Red text indicates an error at some point in the lifecycle of the change item. For example, an issue was previously promoted or approved, and then the item was subsequently rejected. If an error occurred during any of that, the text will turn red.
My Changes page		black or red	Error. Appears next to a change that could not be promoted because of an unknown error. Re-promoting the change may resolve the error. Red text indicates an error at some point in the lifecycle of the change item. For example, an issue was previously promoted or approved, and then the item was subsequently rejected. If an error occurred during any of that, the text will turn red.