You are here:
Change Sets Implementation Tips
Review these tips before you implement your change sets.
Authorization required to upload changes
Before you can deploy a change set from one org to another, an administrator in the target org must authorize uploads across the deployment connection between the two orgs.
Deployment Connections list displays all connections
The Deployment Connections list is automatically populated with your production org and all sandboxes. It is possible to deploy between any of these orgs, but no other orgs.
Change set connections unavailable during maintenance
Authorizing deployment connections and uploading pages require information from the production org, and are unavailable when production is undergoing maintenance. During this time, you can construct outbound change sets but not upload them.
Sandboxes must be available
If an org has no sandboxes provisioned, the user could see an Insufficient Privileges error on the Deployment Connections page.
Deployment doesn’t automatically restart
If an error occurs during change set validation or deployment, you must manually restart the process. Be sure that your org is not locked, undergoing maintenance, or otherwise inaccessible.
Deployment is a one-way transaction
A change set is deployed in a single transaction. If the deployment is unable to complete for any reason, the entire transaction is rolled back. After a deployment completes successfully, all changes are committed to your org and the deployment can’t be rolled back.
Deployments maintain user references
If a component in a change set refers to a specific user, such as recipients of workflow email notifications or dashboard running users, then during deployment the system attempts to locate a matching user in the destination org by comparing usernames.
When you copy data to a sandbox, the fields containing usernames from the production org
are altered to include the sandbox name. For example, in a sandbox named test, the username user@acme.com becomes user@acme.com.test.
During a deployment using change sets, the .test in the
username is ignored. This process transfers a user added to a component in one sandbox to
other sandboxes or production orgs.
Change sets with many dependent components
Opening a change set in Salesforce can take several minutes if it contains a component with many dependencies or if a component’s parent has many dependencies. The delay is because Salesforce checks component dependencies before displaying the change set page. An example of a component with many dependencies is a custom field that belongs to a custom object with 2,500 dependent components.
Action overrides in change sets
An action override is pulled into a change set if the override is associated with a custom object or app that is included in the change set.
Because you can’t include standard objects in a change set, you can’t use a change set to deploy an action override associated with a standard object.

