Deploying Salesforce Sandbox Configuration Changes to Production Using Metadata API, Change Sets, and Packages

Many organizations use a Salesforce Sandbox as an environment to develop and test configuration changes before deploying to their Production instance. You can refresh a Sandbox from Production, but deploying changes in the opposite direction (Sandbox to Production) requires a deliberate deployment approach.

Overview of Deployment Methods

The two primary methods for deploying Salesforce configuration changes from Sandbox to Production are:

1. Unmanaged Packages — Suitable for quick, simple deployments of supported component types.
2. Metadata API Tools — Suitable for more complex or comprehensive deployments using VS Code, SFDX, or the Ant Migration Tool.

Package Approach

An unmanaged package bundles your development work as a private, password-protected Force.com AppExchange package, which can then be installed into your Production instance.
Benefits:

• Faster, simpler deployment
• Minimizes errors

What Can Be Packaged

The following component types can be included in an unmanaged package:

• Attachments (to email templates)
• Custom links
• Custom objects (including custom fields, relationships, picklist values, page layouts, related list layouts, search layouts, public list views, and custom links)
• Custom reports
• Custom S-controls
• Custom tabs
• Dashboards
• Documents
• Email templates (including letterheads)
• Folders
• Profiles
• Custom apps

Package Considerations

• Page layouts associated with Standard Objects cannot be packaged.
• Data cannot be packaged.
• Unmanaged packages can only install new items to an org — they cannot modify items already present in the destination org.
• Managed packages are intended for AppExchange apps for sale and are not appropriate for sandbox-to-production deployments.

Steps to Deploy Using an Unmanaged Package

To make sandbox configuration changes available for copy to production or another sandbox:

1. Create a new unmanaged package on the source org: navigate to Setup > Create > Packages. Provide a name, version, description, and click Save.
2. In the Package Components section, click Add.
3. Select the Component Type from the picklist, then check the boxes for items to include in the package.
4. Click Add To Package before changing the Component Type again.
5. Click Cancel when done adding components.
6. Click Upload on the package main screen and wait for the installation URL to be provided (also emailed to you).

To install that package in a different org:

1. Use the URL produced above. If copying to a production org, change "test.salesforce.com" to "login.salesforce.com" in the URL.
2. Follow the installation steps to download the changes.

Viewing Salesforce Schema

To view and compare the Salesforce schema between two instances (for example, Sandbox vs. Production), you can use the Enterprise WSDL or a schema comparison tool.
Snapshot is an AppExchange tool that provides schema documentation and comparison capabilities. Key features include:

• Comparing configurations over time or between two instances (Sandbox vs. Production).
• Inspecting security settings by profile.
• For Metadata API-supported changes, Snapshot can write changes to the destination org.

Note: Verify that any third-party tools referenced in this article are still current and supported before using them.

Salesforce Change Sets Documentation- https://help.salesforce.com/s/articleView?id=platform.changesets.htm&type=5

Metadata API Developer Guide- https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_intro.htm

Salesforce CLI (SFDX) Setup Guide- https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_intro.htm