16.2 Unlocked Packages, Metadata API & Salesforce DX

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.2 Unlocked Packages, Metadata API & Salesforce DX

Key Takeaways Explain This Topic AI

The Metadata API retrieve/deploy model (often via package.xml manifests) underpins change sets, Workbench, and CLI deploys—think metadata types and members, not rows of data

Salesforce DX source format organizes metadata as project files for Git, scratch orgs, and repeatable CLI workflows ( sf project deploy / retrieve families)

Unlocked packages support modular, versioned delivery of first-party apps with dependency management—strong fit for shared libraries and multi-team orgs

Managed packages (AppExchange) protect IP with namespaces and differ from unlocked packages used mainly for internal modularization

CI/CD wires auth, deploy, and Apex tests into pipelines; package versions create installable, repeatable artifacts rather than one-off change sets

Last updated: August 2026

16.2 Unlocked Packages, Metadata API & Salesforce DX

Quick Answer: The Metadata API is the platform contract for retrieve and deploy of configuration and code. Salesforce DX puts that metadata into a source-format project you can version in Git and push with the Salesforce CLI . Unlocked packages version modular first-party apps for repeatable installs; managed packages power many AppExchange solutions with namespaces and IP protection. For Platform Developer I, know the concepts, CLI deploy awareness, and how packaging beats ad-hoc change sets for complex delivery—not every CLI flag by rote.

Change sets teach the promotion story; this section upgrades you to the tooling professional teams actually automate.

Metadata API: The Common Substrate

Almost every deployment tool speaks Metadata API ideas:

Metadata types — e.g., ApexClass , CustomObject , Flow , LightningComponentBundle , Profile
Members — specific components within a type
Manifest ( package.xml ) — declares what to retrieve or deploy
Deploy — push a zip/source bundle into a target org
Retrieve — pull metadata from an org into a local project

Workbench, Ant migration tool (legacy), change sets under the hood, and modern CLI commands all orbit this model. Exam takeaway: deployment is about metadata descriptions of the org , not exporting CSV records.

Deploy Versus Retrieve

Operation Direction Typical use
Retrieve Org → project Capture existing config, bootstrap source control, compare environments
Deploy Project → org Release features, sync a scratch org, promote a branch

Deploys can be check-only (validate) or real applies—mirroring change set validate vs deploy, but scriptable.

Salesforce DX and Source Format

Salesforce DX is the developer experience centered on:

Source-driven development — Git is the source of truth, not an untracked sandbox.

Project structure — sfdx-project.json , force-app (or multiple package directories), DX source format files.

Scratch orgs — short-lived, shape-defined environments for feature branches.

CLI — authenticate, create orgs, push/pull or deploy/retrieve, run tests, generate package versions.

Source format breaks many metadata types into developer-friendly files and folders (for example, LWC bundles as HTML/JS/XML sets) rather than opaque monolithic XML blobs only. That enables meaningful diffs in pull requests: reviewers see the field or method that changed.

Contrast with “org-based development”: code only in a long-lived sandbox, change sets for promotion, weak history. DX does not forbid sandboxes—it sequences scratch/dev → integration → UAT → production with source as the thread.

Salesforce CLI Deploy Commands (Overview)

Exact command names evolve ( sfdx → sf plugin style), so the exam cares about capabilities more than memorizing every switch. You should recognize that developers use CLI to:

Authorize orgs ( sf org login family)
Deploy project metadata to a target ( sf project deploy start and related validate/async options)
Retrieve metadata into the project
Run Apex tests during or after deploy
Create and install package versions for unlocked/managed packaging workflows

Common mental flags (conceptually):

Dry-run / validate-only — compile and test without keeping the apply
Test level — NoTestRun (non-prod constraints apply), RunSpecifiedTests, RunLocalTests, RunAllTestsInOrg
Manifest vs source path — deploy from package.xml or from directory paths
Wait / async — long deploys polled for status

If a scenario says “automate promotion on every merge to main,” the answer points to CLI + CI , not clicking outbound change sets.

Unlocked Packages (Modular First-Party Delivery)

Unlocked packages let you carve an org’s metadata into versioned modules —for example, a shared “core” library package, an “billing” app package, and an “integrations” package—each with its own release cadence.

Why unlocked packages exist

Problem with giant change sets Unlocked package response
One mega payload, hard to review Smaller, coherent modules
“Works on my sandbox” only Installable versions with dependencies
No semantic versioning Version numbers and upgrade paths
Shared Apex copied everywhere Depend on a core package instead of clone

Characteristics (exam-level):

Designed for customer-owned (first-party) modularization—not primarily AppExchange IP lock-down.

Metadata remains unlocked in the subscriber sense relative to managed packaging restrictions (you retain flexibility to modify in ways managed packages often prevent).

Support dependencies between packages (billing depends on core).

Promote via package version create → install that version in target orgs (sandbox, then production).

You still need good design: package boundaries should follow stable APIs and shared objects carefully. Circular dependencies and “everything in one unlocked package” defeat the purpose.

Managed Packages and AppExchange (High Level)

Managed packages are the classic vehicle for ISV / AppExchange products:

Namespace prefixes components (e.g., myns__ ).

Stronger IP protection and upgrade rules for subscribers.

Versioned releases over customer orgs.

Different packaging rules and limitations than unlocked packages.

Platform Developer I rarely requires building an AppExchange listing, but you must distinguish :

Managed → distribute protected apps to many customers (AppExchange mental model).

Unlocked → modularize and version your enterprise’s metadata.

Change sets / unpackaged Metadata API deploy → ad-hoc or pipeline deploys without package version artifacts.

AppExchange solutions can also appear in requirements as “install a package” rather than rebuild features—know that installed managed packages are not the same as your team’s unlocked modular apps.

Package Versioning (High Level)

Regardless of unlocked vs managed:

Develop in source (feature branch).

Build a package version (immutable-ish artifact of that metadata snapshot).

Install or upgrade that version in a test org.

Promote the same version identity toward production after validation.

Versioning gives release managers a sentence like “production is on core@1.4.0 and billing@2.1.0 ,” which change sets never express cleanly. Failed experiments stay off production; you install only versions that passed CI.

CI/CD Awareness

Continuous Integration / Continuous Delivery for Salesforce typically:

Developer opens a PR with source changes.

Pipeline authenticates a CI integration user or JWT auth to a scratch org or integration sandbox.

Pipeline deploys the branch and runs Apex tests .

On merge, another job deploys to a shared environment or creates a package version .

Production promotion is gated (approvals, release windows, additional test levels).

Benefits exam writers care about: repeatability, early test failure, auditability, reduced “clickops” drift. CI does not remove the need for 75% coverage or thinking about destructive changes—it enforces gates consistently.

Choosing the Right Tool

Scenario Prefer
Small hotfix between related sandboxes, UI-only ops team Change set
Scripted deploy from Git to any org Metadata API via CLI
Multi-team modular enterprise app Unlocked packages + CI
Selling/installing a namespaced product Managed package / AppExchange
Ephemeral feature validation Scratch org + source push/deploy
Common Pitfalls

Treating DX as “only scratch orgs”—sandboxes remain valid targets for deploy.

Forgetting that package install and metadata deploy both still run into Apex test and coverage rules on production.

Confusing data migration with package install.

Assuming unlocked packages provide managed-package IP protection—they do not replace managed packaging for ISV lock-down.

Hand-editing production while also deploying from Git—source drift.

Exam Focus Checklist

Metadata API = retrieve/deploy metadata via types/members/manifests.

DX source format + CLI enable Git-centric, automatable delivery.

Unlocked packages = modular, versioned, first-party delivery with dependencies.

Managed packages = AppExchange/namespace/IP-oriented model.

CI/CD = automated deploy + test gates on every meaningful change.

Pick tools by scale and automation need, not habit alone.

When a question describes “versioned modules shared across teams with automated installs,” answer unlocked packages + CLI/CI . When it describes “related sandbox UI promotion of a few components,” change sets still win. When it describes “retrieve CustomObject XML for source control,” that is Metadata API / DX retrieve territory.