Salesforce DX: What Every Delivery Leader Must Know

What Salesforce DX Is

Salesforce DX (Developer Experience) is a set of tools, practices, and platform capabilities introduced in 2017 to bring modern software development practices to Salesforce delivery. At its core, SFDX is three things: the Salesforce CLI (a command-line tool for all org operations), a source-format for metadata (XML-based files that represent org configuration), and a development model that treats source control as the authoritative state of the org.

Before SFDX, Salesforce development was org-centric: developers made changes directly in a sandbox, then retrieved metadata and deployed it. The org was the system of record. With SFDX, the model inverts: source control is the system of record, and the org is a deployed instance of what is in source control. This sounds like a small philosophical shift — its delivery implications are significant.

SFDX also introduced scratch orgs: short-lived, disposable Salesforce environments that can be created from scratch in minutes based on a configuration definition. A developer can spin up a fresh org, apply their feature's metadata, run tests, and destroy it — all in an automated pipeline without touching any shared sandbox.

Source-Driven vs Org-Driven Development

Understanding the difference between these two development models helps leaders assess whether their team is working in a sustainable, auditable way.

Org-driven development (the old model): Developers open a sandbox, make changes, use "Retrieve" to export the metadata to their local machine, commit it to Git, and use "Deploy" to push to other environments. The org is the primary workspace; source control is a secondary backup. Problems: developers forget to retrieve after changes; multiple developers overwrite each other's work; the production org drifts from what's in source control; deployments are manual and error-prone.

Source-driven development (SFDX model): Source control is the primary workspace. Developers pull the latest source, push to a scratch org or sandbox, make and test changes, retrieve the delta back to source, and merge via a pull request. The pipeline deploys from source to environments. The org is a derivative of source control, not the other way around. Problems solved: drift is eliminated, changes are tracked, pipelines are automated, reviews happen before deployment.

A team genuinely practicing source-driven development can answer: "What is the exact set of metadata deployed in production right now?" with confidence — it is the latest commit on the main branch. A team practicing org-driven development usually cannot answer this question accurately.

Scratch Orgs: The Developer Workflow

Scratch orgs are the most visible SFDX feature for development teams. They are temporary Salesforce orgs (default lifetime: 7 days, maximum: 30 days) created from a definition file that specifies the org's shape — which features are enabled, which Salesforce edition it simulates, and which settings are configured.

The workflow: a developer creates a scratch org, pushes the project's source (from Git) to the scratch org, writes their feature, retrieves changes back to source, runs automated tests, and the scratch org is discarded when development is done. No shared sandboxes are polluted with half-finished features; no developers are blocked waiting for a shared environment; no sandbox refresh is required to get a clean state.

Scratch orgs are appropriate for feature development and automated testing. They are not appropriate for UAT (scratch orgs cannot carry data), performance testing, or integration testing with external systems (scratch org URLs change each time, breaking OAuth configurations).

# Creating and using a scratch org
sf org create scratch \
  --definition-file config/project-scratch-def.json \
  --alias myFeatureDev \
  --duration-days 7

# Push local source to the scratch org
sf project deploy start --target-org myFeatureDev

# Run tests
sf apex run test --target-org myFeatureDev --wait 10

# Pull any changes made in the org back to source
sf project retrieve start --target-org myFeatureDev

Second-Generation Packaging (2GP)

Second-Generation Packaging (2GP) is the SFDX-based approach to defining explicit, versioned packages of Salesforce metadata. Unlike an org's flat metadata pool (where everything exists together in one space), 2GP packages define clear boundaries: "this package contains these specific objects, classes, and flows."

For enterprise delivery teams (as opposed to ISVs building AppExchange products), 2GP provides modularity benefits: different teams own different packages, dependencies between packages are explicit and enforced, and each package can be versioned and deployed independently. A shared core package (company data model standards) can be a dependency of multiple team packages without each team duplicating it.

2GP is the recommended model for complex enterprise implementations with multiple teams — but it is not appropriate for every situation. Smaller implementations, single-team projects, and orgs with highly intertwined metadata may have more overhead from package management than benefit. The decision to adopt 2GP should be made at programme initiation, not retrofitted mid-project.

What a Mature SFDX CI/CD Pipeline Looks Like

A mature Salesforce CI/CD pipeline built on SFDX typically includes these stages, automated end-to-end.

Developer push → Pull request: Developer pushes source changes to a feature branch and creates a pull request. The pipeline automatically creates a scratch org, deploys the feature branch source, runs unit tests, and runs a static code analysis (PMD/Code Analyser). PR cannot be merged if tests fail or code analysis detects critical issues.

Merge to develop → Integration sandbox deploy: Merged code is automatically deployed to the integration sandbox where integration tests run. This catches conflicts between features merged from multiple developers.

Release branch → UAT sandbox deploy: A release branch cut from develop is deployed to the UAT sandbox. Manual UAT testing happens here against the full data set.

Production deploy: After UAT sign-off, the release branch is deployed to production via the pipeline. No manual metadata deployments from a developer's machine — the pipeline is the only deployment mechanism.