16.1 Change Sets & Metadata Deployment

Salesforce Certified Platform Developer I Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Blueprint Weights & Study Strategy

2 Platform Fundamentals

2.1 Multi-Tenant Architecture & Shared Resources 2.2 MVC Mapping on the Lightning Platform 2.3 Declarative vs Programmatic Decisions 2.4 Agentforce for Developers: Use Cases & Limitations

3 Data Modeling & Schema

3.1 Objects, Fields & Schema Design 3.2 Relationship Types & Implications 3.3 Schema Design Impact on Apex 3.4 Data Import & Export for Development

4 Platform Data Features

4.1 Formula Fields & Roll-Up Summaries 4.2 Core CRM Objects & Standard Schema 4.3 AppExchange Extensions & Platform Boundaries

5 Declarative Process Automation

5.1 Record-Triggered Flows & Declarative Automation 5.2 Approval Processes & Business Rules 5.3 When to Use Apex vs Declarative Tools

6 Apex Language Basics

6.1 Variables, Constants & Apex Data Types 6.2 Lists, Sets & Maps 6.3 Control Flow & Exception Handling 6.4 Classes, Interfaces & OOP Patterns

7 SOQL, SOSL & DML

7.1 SOQL Query Fundamentals 7.2 SOSL Search Fundamentals 7.3 DML Operations & Bulkification 7.4 Governor Limits & Transaction Boundaries

8 Apex Triggers & Order of Execution

8.1 Trigger Structure & Context Variables 8.2 Bulk Trigger Patterns & Best Practices 8.3 Save Order of Execution 8.4 Recursion, Cascading & Transaction Control

9 Asynchronous Apex

9.1 @future Methods 9.2 Queueable Apex 9.3 Batch Apex 9.4 Schedulable Apex & Job Orchestration

10 Security, Events & Schema Access

10.1 Sharing, FLS, CRUD & Injection Prevention 10.2 Platform Events Publish & Subscribe 10.3 Programmatic Schema Access (Describe)

11 Visualforce

11.1 Visualforce Pages & Markup 11.2 Standard, Custom Controllers & Extensions 11.3 Visualforce in Lightning Experience

12 Lightning Components

12.1 Lightning Component Framework Benefits 12.2 Aura Component Structure & Resources 12.3 Lightning Web Components Fundamentals 12.4 LWC Data Access: Wire, Imperative & Events

13 UI Composition & Apex Integration Patterns

13.1 Composing UI in Lightning Apps 13.2 UI Security, Performance & Accessibility Patterns 13.3 Apex Actions for Flow, LWC, and Agentforce

14 Apex Testing

14.1 Testing Framework & Coverage Requirements 14.2 Writing Unit Tests for Triggers & Classes 14.3 Test Data Strategies & Isolation 14.4 Executing Tests & Execute Anonymous Differences

15 Debugging & Developer Tools

15.1 Debug Logs & Monitoring 15.2 Developer Console, CLI, VS Code & Workbench 15.3 Sandboxes, Scratch Orgs & Environment Strategy

16 Deployment & Release

16.1 Change Sets & Metadata Deployment 16.2 Unlocked Packages, Metadata API & Salesforce DX 16.3 Release Readiness & Credential Maintenance

16.1 Change Sets & Metadata Deployment

Key Takeaways Explain This Topic AI

Change sets move metadata (not records) between orgs that share a deployment connection—typically sandbox to sandbox or sandbox to production in the same production lineage

Create and upload an outbound change set in the source org; the target receives an inbound change set to validate or deploy

Validate runs Apex tests and dependency checks without committing; deploy applies the package when validation succeeds and you confirm

Change sets lack modern source control, partial component selectivity, and automated CI—prefer Metadata API / Salesforce DX for complex delivery while still knowing change sets for the exam

Profiles and permission sets in change sets are high-risk: they can overwrite broad security settings—prefer permission sets, permission set groups, or carefully scoped profile deltas

Last updated: August 2026

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:

Concern Examples How it usually moves

Metadata Custom objects/fields, Apex classes/triggers, Lightning components, Flows, validation rules, page layouts, permission sets, custom labels Deploy tools: change sets, Metadata API, Salesforce CLI, packages

Data Account records, custom object rows, files, Chatter posts Data Loader, Bulk API, import wizards, ETL—not change sets

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:

Developer / Developer Pro sandbox for feature work
Partial Copy / Full or dedicated QA sandbox for integration and UAT
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:

Create an outbound change set with a clear name and description (include ticket or release ID).

Add components —Apex classes, triggers, custom fields, objects, Lightning bundles, Flows, remote site settings, custom metadata types, and many other deployable types.

Use View/Add Dependencies (or equivalent) so required related metadata is included—missing custom fields, named credentials, or custom labels are classic deploy failures.

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:

Open Inbound Change Sets and locate the uploaded package.

Validate (recommended first for production-bound releases).

Deploy when validation is clean and the release window is open.

Validate Versus Deploy

Action What it does When to use

Validate Compiles metadata, resolves many dependencies, runs the selected Apex test level without committing the change set permanently as the live package outcome Pre-flight every production-bound set; prove 75%+ coverage and green tests

Deploy Applies the metadata into the target (subject to test requirements and permissions) After successful validation (or in lower envs when risk is accepted)

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 :

Change sets Metadata API / Salesforce DX / packages
UI-driven component picking Source format in Git; repeatable CLI deploys
Related orgs only Any authorized org via auth + deploy
Weak audit of “what changed in Git” Branching, PR review, CI pipelines
Awkward for large modular apps Unlocked/second-generation packaging
Manual dependency hunting Manifest ( package.xml ) and source tracking
Limited automation sf project deploy in CI/CD

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

Missing dependency — deployed class references a field or label not in the set.

Test failure / coverage — validation fails org-wide coverage or a failing test.

Wrong target / connection — upload succeeded but inbound list empty.

Profile overwrite — security drift after deploy.

Assuming data moved — users expect records; only metadata arrived.

Manual steps forgotten — named credentials secrets, remote site confirmations, feature licenses, or post-deploy config.

Exam-Oriented Workflow

Memorize this story for scenario questions:

Develop and unit test in a sandbox (or scratch org in modern shops).

Add only metadata components + dependencies to an outbound change set.

Upload after connection is enabled.

In target, validate with appropriate tests.

Fix issues in source; repeat as needed.

Deploy in the release window; run smoke checks.

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.