Validating and Deploying Change Sets

Why This Topic Matters

Change sets are the native, declarative way to move configuration (metadata) between related Salesforce orgs, most commonly from a sandbox into production. Every Advanced Administrator is expected to manage the application lifecycle: build in a sandbox, test, and promote changes safely without breaking production. The exam's Environment Management and Deployment section tests whether you understand not just how to click through a change set, but when to validate, which Apex test option to choose, what can and cannot be deployed, and how to troubleshoot a failed deployment. Mistakes here are costly in real life (a broken production org), so Salesforce weights these concepts accordingly.

What Is a Change Set?

A change set is a container of metadata components (custom objects, fields, page layouts, validation rules, Apex classes, flows, reports, dashboards, profiles, permission sets, and so on) that you package in one org and send to another related org. Key definitions:

• Outbound Change Set – created in the source org (usually a sandbox). You add components, optionally add dependencies and profile settings, then upload it to a target.
• Inbound Change Set – the same change set as it appears in the target org (usually production or another sandbox). Here you validate or deploy it.
• Deployment Connection – change sets can only travel between orgs that share a production org (production and its sandboxes). The target org must explicitly authorize inbound changes from the source org in Setup > Deployment Settings. Authorization is one-directional: allowing sandbox-to-production does not automatically allow production-to-sandbox.
• Deployment Status – the Setup page in the target org where you monitor in-progress, succeeded, and failed deployments, review error messages, and perform a Quick Deploy.

Important characteristics to memorize:
• Change sets move metadata only, never record data.
• Change sets cannot delete components in the target; removals must be done manually or via the Metadata API/destructive changes.
• Once uploaded, a change set cannot be edited. To make a change you clone it, modify the clone, and upload again.
• Deployments are all-or-nothing (atomic). If one component fails, nothing is committed.
• Limits: up to 10,000 files and 400 MB per change set.
• Not every component type is supported (for example, some org-wide settings, standard picklist values, certain Lightning settings, and most data such as approval process-related records). Unsupported items require manual configuration in the target.
• Profiles added to a change set carry permissions only for the components in that change set (plus a few settings), not the entire profile.

How It Works: End-to-End Process

Step 1 – Authorize the connection. In the target org (e.g., production), an admin goes to Deployment Settings and allows inbound changes from the source sandbox.

Step 2 – Build the outbound change set. In the source sandbox: Setup > Outbound Change Sets > New. Name it, add components, then click View/Add Dependencies to pull in required related components (for example, a custom field referenced by a validation rule). Add profiles or permission sets if field-level security or object permissions must travel with the fields.

Step 3 – Upload. Select the target org and upload. The change set appears in the target's Inbound Change Sets list after a short processing delay (usually minutes, sometimes longer).

Step 4 – Validate (recommended). In the target org, open the inbound change set and click Validate. Validation runs every check a real deployment would run, including Apex tests according to the chosen test level, but commits nothing. It reveals missing dependencies, component errors, and test failures in advance. Validation results appear on the Deployment Status page.

Step 5 – Deploy. Click Deploy and choose the Apex test option. If validation already succeeded, you may instead use Quick Deploy from Deployment Status.

Step 6 – Post-deployment tasks. Many items need manual follow-up: activating flows or processes that deployed as inactive (unless the org setting to deploy flows as active is enabled), adjusting unsupported settings, scheduling Apex jobs, updating email deliverability, enabling features, loading data, and communicating to users.

Apex Test Options (Test Levels)

When validating or deploying into a production org, Salesforce requires Apex tests when Apex code is involved. The four options:

• Default – In production, if the change set contains Apex classes or triggers, Salesforce runs all local tests (equivalent to Run Local Tests). If the change set contains no Apex, no tests run. In a sandbox, Default runs no tests.
• Run Local Tests – Runs all tests in the org except those in installed managed packages. This is the most common choice for production and is required for Quick Deploy eligibility.
• Run All Tests – Runs every test, including managed package tests. Slowest; use when a managed package interaction must be verified.
• Run Specified Tests – Runs only the test classes you list. Every Apex class and trigger in the change set must have at least 75% coverage individually from the specified tests, and all must pass.

Production requirements regardless of option: 75% overall Apex code coverage and zero test failures. Triggers must have at least some coverage. Sandbox deployments do not enforce coverage unless you choose to run tests.

Quick Deploy

Quick Deploy lets you deploy a change set that was recently validated without rerunning Apex tests, dramatically shortening the production deployment window. Requirements:
• The validation succeeded (no component errors, all tests passed, coverage met).
• Tests were run at the Run Local Tests or Run All Tests level (or Default where it ran all local tests), not Run Specified Tests.
• The Quick Deploy is performed within 10 days of the validation.
• The target org's relevant metadata has not changed since validation (otherwise Salesforce invalidates the quick deploy).
Quick Deploy is initiated from the Deployment Status page, not from the inbound change set itself.

Permissions Needed

• Source org: Create and Upload Change Sets (plus Create AppExchange Packages / Upload AppExchange Packages on older orgs).
• Target org: Deploy Change Sets and Modify All Data; Author Apex is needed when Apex is involved.

Common Deployment Failures and Fixes

• Missing dependency – a referenced field, object, record type, or Apex class is not in the change set or the target. Fix: use View/Add Dependencies, or deploy prerequisites first.
• Test failure / insufficient coverage – fix or add test classes in the sandbox, redeploy.
• Unsupported component – configure manually in the target.
• Field-level security missing after deploy – profiles/permission sets were not included; add them or set FLS manually.
• Change set not visible in target – deployment connection not authorized, or still processing.
• Deploying a field type change – some data-type changes are not allowed via change sets or cause data loss warnings; handle manually.

Best Practices the Exam Rewards

• Build in a Developer or Developer Pro sandbox, test in a Partial Copy or Full sandbox, then deploy to production.
• Always validate first, then use Quick Deploy during a low-usage window.
• Deploy in logical order when dependencies cannot all fit in one set (objects/fields first, then automation, then layouts/profiles).
• Keep a release checklist of manual pre- and post-deployment steps.
• Use change sets for sandbox-to-production in the same org family; use unmanaged packages, Metadata API, or Salesforce CLI/DevOps Center when moving between unrelated orgs or when deletions and source control are needed.

Exam Tips: Answering Questions on Validating and Deploying Change Sets

1. Spot the direction. If the question says a change set is not appearing in production, the almost-certain answer involves the target org not authorizing inbound changes in Deployment Settings. Remember: authorization happens in the receiving org.

2. Validate vs. Deploy. When a scenario emphasizes minimizing risk, checking for errors without affecting users, or confirming test results before a weekend release, the answer is Validate. When the scenario emphasizes reducing deployment time after a successful validation, the answer is Quick Deploy.

3. Know the 75% rule and the 10-day window. Numbers are favorite exam targets: 75% overall Apex coverage in production, every class/trigger 75% with Run Specified Tests, Quick Deploy within 10 days of validation, 10,000 files / 400 MB limit.

4. Match the test level to the clue. 'Exclude managed package tests' = Run Local Tests. 'Verify an AppExchange package integration' = Run All Tests. 'Run only a handful of tests to save time but still meet coverage per class' = Run Specified Tests. 'No Apex in the change set deploying to production' = Default runs no tests.

5. Change sets cannot delete or move data. Any option suggesting a change set will remove a field, delete a report, or migrate records is a distractor. Deletions are manual or via Metadata API destructive changes; data moves via Data Loader or Data Import Wizard.

6. Uploaded means frozen. If a component was forgotten, the correct action is to clone the change set (or create a new one), add the component, and upload again, not edit the uploaded set.

7. Profile and FLS questions. If users cannot see newly deployed fields, the change set lacked profiles or permission sets. Remember profiles in a change set include settings only for components also in the change set.

8. Related orgs only. Change sets work between a production org and its sandboxes (or sandbox to sandbox of the same production). Moving metadata to an unrelated org calls for an unmanaged package, Metadata API, or Salesforce CLI.

9. Flows and processes deploy inactive (by default). If a question says the automation is not firing after deployment, the answer is to activate it in the target (or enable the deploy-as-active setting with sufficient test coverage).

10. All-or-nothing. If one component fails, no components deploy. Answer choices implying partial deployment are wrong for change sets.

11. Read for the sandbox type. Questions about testing with realistic data volumes point to a Full sandbox; configuration-only development points to Developer/Developer Pro. Deployment should flow from lower to higher environments ending in production.

12. Eliminate code-heavy answers. The Advanced Administrator exam favors declarative solutions. When a change set can accomplish the goal, options involving writing Apex or using third-party tools are usually distractors, unless the requirement (deletions, unrelated orgs, version control) is explicitly outside change set capabilities.

Master the mechanics (connection, outbound, upload, inbound, validate, deploy, post-steps), the test levels, the key numbers, and the limitations, and you will be able to answer virtually any change set scenario the exam presents.