An Introduction to Change Sets and Sandboxes

American coins (also a jigsaw puzzle )

In terminology, promoting changes from one organization to another is called migration. There are currently two methods for migrating changes between salesforce organizations. One method is to use Change Sets. This article will introduce you to Change sets and Sandboxes.

Change Sets are a mechanism for bundling up changes from one Salesforce organization to another. However, all of the Salesforce organizations must be related to one another. That is, Change Sets are limited to a Production organization and any sandboxes created from it. They cannot be used to deploy changes from a different Developer Organization.

Depending on the edition of Salesforce that you are using, Sandboxes may not be an option for you. At the time of this writing, the Enterprise Edition comes with one developer sandbox and the Unlimited Edition comes with 15 developer sandboxes, 5 configuration-only sandboxes and 1 full copy sandbox. If you are using the Professional or Group Editions, sandboxes are not available.

The only difference between a developer sandbox and a configuration-only sandbox is the amount of data that each can contain. A developer sandbox is limited to a total of 10 MB while a configuration only sandbox is limited to 500 MB of data. For the most part, data for standard objects and custom objects is not included, although there are a few exceptions such as price books and products. These sandboxes will also include reports, dashboards, apps as well as customizations found in the production organization at the time of creation or a refresh. Refreshing developer and configuration-only sandboxes can occur once per day.

A full copy sandbox is a duplicate of your entire production organization. Everything is copied over, making it ideal for pre-production testing before rolling out new functionality, whether that is a new package from the AppExchange or your own customizations. Because of potential for containing a large amount of data, Salesforce limits the ability to refresh a full copy sandbox to every 29 days.

Creating a sandbox does not automatically enable Change Sets to be moved from sandbox to sandbox. A Deployment Connection needs to be established between each organization. In addition, you must specify the direction in which Change Sets are allowed to flow, either Inbound or Outbound or both.

What have you noticed about working with Change Sets, Sandboxes and Deployment Connections?

This entry was posted in Change Sets,, Sandbox. Bookmark the permalink.

1 Response to An Introduction to Change Sets and Sandboxes

  1. If you want to move data as well, I’ve been developing an application over the past month which is built specifically for this. I run into this same exact issue at my day job so I decided that i will develop this since i’m sure others have run into this same issue. I’m surprised that salesforce doesnt offer some mechanism to do this. I guess they make too much $$ off thier sandboxes.

    Anyways, it’s called SFXOrgData,, and lets you copy data from Production into any type of sandbox. This also gets around the 30 day refresh limitation on full-sandboxes.

    If the sandbox already contains a copy of the production data, it also uses External Ids to update the existing records rather than creating new ones.

    Also, the app lets you filter the data you want to copy so you dont hit any size limits on the destination sandbox.

    Since it’s build specifically for Salesforce to Salesforce, it also has the ability to disable stuff like validation rules and triggers during the transfer.

Comments are closed.