16.1 Change Sets & Metadata Deployment

16.1 Change Sets & Metadata Deployment

Quick Answer: A change set packages metadata (Apex, objects, fields, Flows, layouts, and more)—not record data—and moves it between related orgs that have an enabled deployment connection (for example, a sandbox → another sandbox or → production). Build an outbound change set in the source, upload it, then validate and/or deploy the inbound change set in the target. Know validation versus deploy, component coverage, profile risk, and when change sets are too limited compared with Metadata API and Salesforce DX.

Platform Developer I treats deployment as a core skill in the Testing, Debugging, and Deployment domain. You must explain how metadata promotes through environments, what change sets can and cannot do, and how validation protects production from broken Apex or missing dependencies.

Metadata Versus Data

Salesforce orgs contain two fundamentally different payloads:

Exam questions often trap candidates who try to “deploy sample Accounts” with a change set. Change sets never move ordinary business records. Seed data, sandbox templates, Partial/Full copy sandboxes, and scripts handle data. Your release process should keep source of truth for metadata (ideally version control) separate from data migration plans.

Deployment Connections and Related Orgs

Change sets work only between orgs that Salesforce treats as related through the production org’s sandbox lineage. Typical path:

1. Developer / Developer Pro sandbox for feature work
2. Partial Copy / Full or dedicated QA sandbox for integration and UAT
3. Production for go-live

In Setup → Deployment Settings (wording varies slightly by UI), an administrator enables which sandboxes may upload change sets to which targets. Until a deployment connection allows inbound deployments from a given source, the target will not show that source’s uploaded packages. Production can receive from authorized sandboxes; you do not use change sets to push arbitrary metadata between two unrelated production orgs or between customer orgs that share no relationship.

Practical implication: If an inbound change set “never appears,” check (1) upload completed in the source, (2) connection is enabled in the target for that source, and (3) you are logged into the correct target org.

Outbound Change Sets (Source Org)

In the source org:

1. Create an outbound change set with a clear name and description (include ticket or release ID).
2. Add components—Apex classes, triggers, custom fields, objects, Lightning bundles, Flows, remote site settings, custom metadata types, and many other deployable types.
3. Use View/Add Dependencies (or equivalent) so required related metadata is included—missing custom fields, named credentials, or custom labels are classic deploy failures.
4. Upload the change set. Upload packages the metadata for the authorized target(s); it does not yet change production.

Common components you should recognize on the exam:

• Apex classes, triggers, and test classes
• Custom objects, fields, record types, page layouts, compact layouts
• Validation rules, Flows (and historically Process Builder/Workflow where still present)
• Lightning web components / Aura components, Visualforce pages and controllers
• Permission sets, profiles (with caution), custom permissions
• Custom labels, static resources, email templates (metadata-backed)
• Custom metadata types and custom settings definitions

Not everything is change-set friendly or complete: some settings remain manual post-deploy steps, and some metadata types have limited or no change set support depending on API/UI generation. When in doubt in real projects, verify the Metadata API type list; for the exam, remember profiles/permissions risk and dependency completeness more than obscure type edge cases.

Inbound Change Sets (Target Org)

In the target org:

1. Open Inbound Change Sets and locate the uploaded package.
2. Validate (recommended first for production-bound releases).
3. Deploy when validation is clean and the release window is open.

Validate Versus Deploy

Salesforce enforces Apex test requirements on deployments into production (and often into sandboxes depending on settings and tooling). Overall org coverage must meet at least 75%, tests must pass, and triggers need coverage. Validation is your cheap rehearsal: fix failures in the source, re-upload if needed, and only then deploy.

Test levels you may see in deployment UIs / API (names slightly vary by tool):

• Run local tests / default production rules
• Run all tests in org
• Run specified tests (useful in CI with Metadata API; change set UI options are more limited historically)

For Platform Developer I, lock this mental model: production deploy without adequate tests and coverage fails; validation surfaces that before users are impacted.

Profiles, Permission Sets, and Security Caution

Including an entire profile in a change set can overwrite large slices of security configuration in the target—object permissions, field-level security, tab visibility, and user interface settings that other teams also own. That makes profiles a frequent source of “we deployed a field and broke Sales’ page layout/visibility.”

Safer patterns:

• Prefer permission sets and permission set groups for additive access.
• If profiles must ship, review diffs carefully and minimize scope.
• Coordinate with admins; treat security metadata as a shared release surface, not a solo developer artifact.

Permission sets still require discipline (do not grant Modify All Data casually), but they avoid the blast radius of full profile replacement.

Limitations of Change Sets Versus Modern Tooling

Change sets remain exam-relevant and useful for small admin/developer promotions, but they show their age next to Salesforce DX and the Metadata API:

When change sets are still fine: small field/Flow/Apex hotfixes between connected sandboxes, teams without DX yet, or exam scenarios that explicitly describe outbound/inbound change sets.

When to prefer DX/API: multi-team releases, destructive changes with review, automated test gates, scratch org development, and unlocked package modular delivery (next section).

Failure Modes to Recognize

1. Missing dependency — deployed class references a field or label not in the set.
2. Test failure / coverage — validation fails org-wide coverage or a failing test.
3. Wrong target / connection — upload succeeded but inbound list empty.
4. Profile overwrite — security drift after deploy.
5. Assuming data moved — users expect records; only metadata arrived.
6. Manual steps forgotten — named credentials secrets, remote site confirmations, feature licenses, or post-deploy config.

Exam-Oriented Workflow

Memorize this story for scenario questions:

1. Develop and unit test in a sandbox (or scratch org in modern shops).
2. Add only metadata components + dependencies to an outbound change set.
3. Upload after connection is enabled.
4. In target, validate with appropriate tests.
5. Fix issues in source; repeat as needed.
6. Deploy in the release window; run smoke checks.
7. Keep profiles out unless carefully reviewed; prefer permission sets.

If the question contrasts tools, answer with capability fit: change sets for related-org UI deploys; Metadata API/CLI for automation and source-driven work; packages for modular versioned delivery.

Master outbound vs inbound, validate vs deploy, metadata vs data, deployment connections, and profile risk—and you will clear classic change-set items quickly while staying ready for DX-oriented follow-ups.