Salesforce Dictionary - Free Salesforce GlossarySalesforce Dictionary
Full Change Set entry
How-to guide

How to deploy a Change Set without surprises

The successful pattern: build the change, add dependencies, validate, deploy. The failed pattern: build the change, deploy, discover missing dependencies in production, scramble to fix. Validate is the safety net; skipping it is the most reliable way to create deployment incidents.

By Dipojjal Chakrabarti · Founder & Editor, Salesforce DictionaryLast updated May 18, 2026

The successful pattern: build the change, add dependencies, validate, deploy. The failed pattern: build the change, deploy, discover missing dependencies in production, scramble to fix. Validate is the safety net; skipping it is the most reliable way to create deployment incidents.

  1. Confirm the Deployment Connection exists

    Setup, Deployment Settings in both orgs. The connection must exist and allow inbound deploys from source to target. Configure once if needed.

  2. Create the Outbound Change Set in the source org

    Setup, Outbound Change Sets, New. Name it descriptively (date, ticket reference, change summary).

  3. Add the metadata components

    Click Add. Pick the component type, select the components. Repeat for each type. The Components list grows as you add.

  4. Run View/Add Dependencies

    Click View/Add Dependencies. Review the list. Add every dependency unless you know the target org already has it. Re-run after adding new components.

  5. Upload the Change Set to the target org

    Click Upload, pick the target connection. The Change Set travels to the target as an Inbound Change Set.

  6. Validate in the target org before deploying

    In the target org, Setup, Inbound Change Sets, find the uploaded set, click Validate. Wait for the dry-run to complete. Fix errors and re-upload if needed.

  7. Deploy after Validate succeeds

    Click Deploy. Pick the test execution scope (run local tests, specified tests, all tests). Wait for completion. Verify the deployed components in the target org.

Source and target connectionremember

The two orgs connected for deployment. Configure once at sandbox creation.

Component selectionremember

Which metadata components are in the Change Set. Use View/Add Dependencies to avoid missing pieces.

Validate vs Deployremember

Validate is a dry-run; Deploy commits. Always Validate first on production.

Test execution scoperemember

Local tests, specified tests, or all tests. Drives required test runtime; pick the right scope to balance coverage and time.

Deployment quick deployremember

After a successful Validate, the Quick Deploy option skips re-running tests on the actual Deploy. Useful for tight production windows.

Gotchas
  • Skipping View/Add Dependencies is the most common deploy failure cause. The target org rejects components that reference missing dependencies.
  • Some newer metadata types are not supported in Change Sets. Confirm component type support before assuming a Change Set is the right path.
  • Production deploys with Apex require 75 percent org-wide test coverage. A sandbox deploy that worked can fail in production if coverage is borderline.
  • Validate and Deploy run tests if Apex is included. Test execution can take 30+ minutes on large orgs; plan for the time.
  • Change Sets cannot be edited after upload. Mistakes require building and uploading a new Change Set; the original cannot be modified in flight.

See the full Change Set entry

Change Set includes the definition, worked example, deep dive, related terms, and a quiz.