Salesforce DX
Salesforce DX (Developer Experience) is the source-driven development toolset Salesforce introduced in 2017 to bring modern software engineering practices to the Lightning Platform.
Definition
Salesforce DX (Developer Experience) is the source-driven development toolset Salesforce introduced in 2017 to bring modern software engineering practices to the Lightning Platform. It bundles the Salesforce CLI, scratch orgs, source format metadata, unlocked packaging, and a set of conventions for using version control as the source of truth for Salesforce metadata. Before DX, the org was the source of truth and metadata moved through change sets or the Ant Migration Tool. After DX, the git repository is the source of truth and the org is rebuilt from it.
The DX model rests on three pillars: source-driven development (your metadata lives in source files committed to git), scratch orgs (disposable orgs spun up from a definition file in under five minutes), and unlocked packages (versioned, deployable units of metadata that replace monolithic change sets). The CLI binds them together. Most modern Salesforce developer workflows, including CI/CD pipelines, automated testing, and AppExchange package development, run on top of Salesforce DX even when developers do not realize the underlying tooling is doing the work.
How Salesforce DX organizes a modern developer workflow
Why Salesforce built DX
Before DX, the org was the master copy. Developers worked directly in a sandbox, made changes through the Setup UI, and used the Force.com IDE or change sets to move metadata. The model worked at small scale but broke down for any team practicing real version control. Two developers editing the same Apex class in two sandboxes was a merge conflict waiting to happen, and the platform offered no help. DX flipped the model: the source repository is canonical, the org is derived. The shift took years to land in customer workflows but is now the default expectation in any serious development team.
The Salesforce CLI
The Salesforce CLI is the command-line tool that drives everything in DX. The modern command name is sf (the older one was sfdx, both still work). It handles org authentication, project scaffolding, metadata deployment, scratch org creation, source retrieval, Apex execution, Apex testing, and data manipulation. The CLI is the only Salesforce-supplied tool that supports the full DX workflow. Editor plugins (VS Code, IntelliJ, Sublime) wrap the CLI but do not replace it. CI/CD pipelines invoke the CLI directly. Learning the CLI is the highest-leverage Salesforce developer skill.
Scratch orgs: disposable, definition-driven
A scratch org is a Salesforce org spun up on demand from a JSON definition file. The definition specifies which features the org should have, which edition (Developer, Enterprise, Performance), which language, which currency, and which preview release. Scratch orgs are temporary, with a default lifespan of 7 days and a maximum of 30. They are deliberately disposable: spin one up, deploy your source, run your tests, throw it away. The model encourages clean state. A developer who depends on long-lived sandbox configuration that no one wrote down cannot benefit from scratch orgs.
Source format vs metadata format
DX introduced a new file layout called source format. Where the old Metadata API stored CustomObject definitions in one giant XML file (Account.object), source format splits it into a folder of small files: one for the object header, one per field, one per record type, one per validation rule. The split makes diffs readable, merges tractable, and ownership traceable. The CLI converts between source format and metadata format automatically. Deployments and retrievals can use either, though source format is the convention for the repository and metadata format is the wire shape for the Metadata API.
Unlocked packages and second-generation packaging (2GP)
Unlocked packages are versioned bundles of metadata. They replace the unmanaged-package model from the old AppExchange days. An unlocked package can be installed into any org, upgraded in place, and uninstalled cleanly. Salesforce calls the broader family second-generation packaging (2GP), which also includes managed 2GP packages for ISVs publishing on AppExchange. The package version is built from source with sf package version create, then installed into a target org with sf package install. Org-dependent unlocked packages skip the dependency tree validation, useful for customer-specific packages that depend on the org's existing metadata.
CI/CD on top of DX
DX is the foundation for modern Salesforce CI/CD. The pattern is: developer commits to a feature branch, CI spins up a scratch org, deploys the source, runs Apex tests, deletes the scratch org. On merge, CI deploys to integration and UAT sandboxes through the same CLI commands. Production deploys use either the metadata-deploy command against a sandbox-promoted package version or the package-install command directly against production. Tools like Copado, Gearset, and Salto layer enterprise workflow on top of these primitives. The underlying mechanics are the CLI commands and source format that DX ships.
Dev Hub: the parent org for scratch orgs
Scratch orgs are spun up from a Dev Hub, a Salesforce org with the Dev Hub feature enabled. Production orgs can be Dev Hubs (with an additional license called Free Limited Access for scratch orgs), or a developer's Trailhead Playground can serve as a Dev Hub for personal projects. The Dev Hub tracks the org's scratch org limits: per-day creation, active count, edition entitlements. Authenticating the CLI to the Dev Hub is the first step in any DX project: sf org login web --alias DevHub --set-default-dev-hub.
Setting up a Salesforce DX project
Setting up a Salesforce DX project means installing the CLI, authenticating the Dev Hub, scaffolding the project, creating a scratch org, deploying source, and running tests. The first run takes an hour. Every subsequent run takes minutes.
- Install the Salesforce CLI
Download the installer from developer.salesforce.com or npm install -g @salesforce/cli. Confirm with sf --version. The CLI auto-updates by default, so no version management is required.
- Enable Dev Hub on the target org
Log into the production or developer-edition org. Setup, Dev Hub, Enable Dev Hub. Save. Without this, the org cannot mint scratch orgs.
- Authenticate the CLI to the Dev Hub
Run sf org login web --alias DevHub --set-default-dev-hub. A browser opens, you log in, the CLI stores the OAuth token locally. Future commands reference the alias instead of re-authenticating.
- Scaffold a new DX project
Run sf project generate --name MyProject. The CLI creates the standard folder structure: force-app/main/default for source, config/project-scratch-def.json for scratch org definitions, sfdx-project.json for package configuration.
- Create a scratch org
Run sf org create scratch --definition-file config/project-scratch-def.json --alias mywork --set-default. The Dev Hub validates and provisions the org in 2 to 5 minutes. The alias is what subsequent CLI commands target.
- Push the source
Run sf project deploy start to push the current local source to the scratch org. The CLI tracks file changes and only sends what is new. For larger projects, sf project deploy start --source-dir force-app/main/default/lwc deploys a subset.
- Run Apex tests
Run sf apex run test --result-format human to execute all tests. Add --code-coverage for the coverage report. CI pipelines use --result-format junit to feed test results into the build system.
The parent org that mints scratch orgs. Enabled once per company in Setup. Production orgs can be Dev Hubs with no additional license cost.
JSON file in config/ that declares the edition, features, language, and preview release for the scratch org. Variants per use case (qa, integration, perf) are common.
The DX folder layout for metadata. The CLI converts to/from metadata format automatically when deploying through legacy paths.
The project manifest that declares package directories, the default package, and the namespace if the org is a managed-package developer.
The 2GP package type for modularizing metadata. Built from source, versioned, and installable into any org without a release branch.
Variant that skips ancestor validation, useful for customer-specific packages that depend on existing org metadata.
- Scratch orgs do not inherit sandbox data. Every scratch org starts empty. Seed data through sf data tree import or a custom Apex script for any test that requires populated records.
- Source format and metadata format are not interchangeable in git. The repository should commit one or the other, not both. The DX convention is source format.
- Dev Hub limits cap how many scratch orgs you can spin up per day and keep active. Enterprise Dev Hubs allow more, but the limit catches small teams off guard.
- Unlocked packages bind to a namespace. Once installed, the namespace prefix appears on all components from that package. Plan namespaces before publishing a package to production.
- The CLI auto-updates by default. Pin the version in CI (sf-plugins-core, JIT updates disabled) for build reproducibility.
Trust & references
Cross-checked against the following references.
- Salesforce DX Developer GuideSalesforce Developers
Straight from the source - Salesforce's reference material on Salesforce DX.
- Salesforce DX Developer GuideSalesforce Developers
- Salesforce CLI Command ReferenceSalesforce Developers
- Unlocked PackagesSalesforce Developers
Hands-on resources to go deeper on Salesforce DX.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Governor Limit in the context of Salesforce DX?
Q2. What is required before deploying Salesforce DX-related code to production?
Q3. What skill set is typically needed to work with Salesforce DX?
Discussion
Loading discussion…