16.2 Unlocked Packages, Metadata API & Salesforce DX

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

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:

1. Source-driven development — Git is the source of truth, not an untracked sandbox.
2. Project structure — sfdx-project.json, force-app (or multiple package directories), DX source format files.
3. Scratch orgs — short-lived, shape-defined environments for feature branches.
4. 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

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:

1. Develop in source (feature branch).
2. Build a package version (immutable-ish artifact of that metadata snapshot).
3. Install or upgrade that version in a test org.
4. 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:

1. Developer opens a PR with source changes.
2. Pipeline authenticates a CI integration user or JWT auth to a scratch org or integration sandbox.
3. Pipeline deploys the branch and runs Apex tests.
4. On merge, another job deploys to a shared environment or creates a package version.
5. 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

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

1. Metadata API = retrieve/deploy metadata via types/members/manifests.
2. DX source format + CLI enable Git-centric, automatable delivery.
3. Unlocked packages = modular, versioned, first-party delivery with dependencies.
4. Managed packages = AppExchange/namespace/IP-oriented model.
5. CI/CD = automated deploy + test gates on every meaningful change.
6. 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.