TutorialKart.comSalesforce DX, or Salesforce Developer Experience, is a source-driven approach to developing and delivering Salesforce applications. It combines Salesforce CLI, project configuration, version control, scratch orgs, development environments, automated testing, packaging, and continuous integration practices.
In a Salesforce DX workflow, the project files in a version control system serve as the shared source of truth. Developers make changes in separate environments, review them through the team’s version control process, test them, and deploy validated metadata to the required Salesforce orgs.
Salesforce DX Developer Experience Explained
Salesforce introduced Salesforce DX in the Winter ’18 release. Earlier Salesforce development commonly treated an org as the primary location for code and configuration. That approach could make it difficult to identify changes, coordinate multiple developers, review metadata, reproduce environments, and roll back a release.
Salesforce DX moves development toward source control and repeatable commands. Apex classes, Lightning components, objects, fields, permission sets, layouts, and other supported metadata can be stored as project files. Git or another version control system can then track revisions and support branches, code reviews, and release tags.
Core Components of a Salesforce DX Workflow
| Salesforce DX component | Purpose |
|---|---|
| Salesforce CLI | Authenticates orgs and runs project, metadata, testing, data, and org-management commands. |
| Salesforce DX project | Stores source files, package directories, scratch-org definitions, and project configuration. |
| Version control | Records changes and supports branches, reviews, merging, release tags, and rollback procedures. |
| Dev Hub | Provides management functions required to create and administer scratch orgs. |
| Scratch org | Provides a temporary, configurable Salesforce environment created from a definition file. |
| Development org | Provides a persistent environment, such as a sandbox or Developer Edition org, when a temporary scratch org is unsuitable. |
| Salesforce Extensions for VS Code | Supports Salesforce project navigation, Apex development, testing, metadata operations, and debugging workflows. |
| Continuous integration | Automates validation, tests, static checks, and deployment commands when source changes. |
Salesforce CLI Commands Used with Salesforce DX
Salesforce CLI provides the sf command used in current Salesforce development workflows. It can create projects and scratch orgs, authenticate environments, deploy or retrieve metadata, import data, assign permission sets, run Apex tests, and open orgs.
After installing Salesforce CLI, verify that the command is available:
sf --versionCLI commands affect the org identified by an alias, username, or configured default. Check the target before running a deployment, data operation, or destructive command.
- Learn how to Install Salesforce DX CLI.
Dev Hub Setup for Salesforce DX Scratch Orgs
A Dev Hub is the Salesforce org associated with the creation and management of scratch orgs. An administrator must enable Dev Hub where required and give developers the permissions needed for the intended workflow.
The following command opens a browser-based login and saves the authenticated Dev Hub with the alias DevHub:
sf org login web --set-default-dev-hub --alias DevHubUse an authentication method appropriate for the environment. Interactive browser login is useful for local development, while continuous integration normally uses a non-interactive, securely managed authentication process.
Salesforce DX Scratch Orgs
A scratch org is a temporary Salesforce environment created for a specific development or testing task. Its edition, features, settings, and other characteristics are described in a scratch-org definition file stored with the project.
Scratch orgs are useful for isolated feature work, automated validation, demonstrations, and package development. They expire after their configured duration and should not contain data or changes that have not been preserved elsewhere. Availability and creation limits depend on the Dev Hub and Salesforce entitlements.
sf org create scratch \
--definition-file config/project-scratch-def.json \
--alias MyScratchOrg \
--set-default \
--duration-days 7After creating the org, deploy the project metadata and open the org:
sf project deploy start --target-org MyScratchOrg
sf org open --target-org MyScratchOrgSalesforce DX Project Structure
A Salesforce DX project is a local directory containing Salesforce source files and configuration. The sfdx-project.json file defines project settings such as package directories, namespace information when applicable, source API version, and package dependencies.
Create a project with Salesforce CLI:
sf project generate --name my-dx-project
cd my-dx-projectA generated Salesforce DX project commonly includes the following items:
sfdx-project.json, the main project configuration file.force-app, the default package directory for Salesforce source.config/project-scratch-def.json, a sample scratch-org definition.- Directories for scripts, configuration, and project-specific supporting files.
Salesforce DX Source Format and Metadata Deployment
Salesforce DX source format organizes metadata for version-control workflows. Some metadata types are decomposed into smaller files so that developers can review changes with less unrelated content. Salesforce CLI converts source as needed when communicating with Salesforce metadata APIs.
Deploy local project changes to an org with:
sf project deploy start --target-org MyScratchOrgRetrieve supported metadata changes from an org with:
sf project retrieve start --target-org MyScratchOrgRetrieving metadata can overwrite local files or introduce changes that conflict with another developer’s work. Commit or otherwise preserve the current project state before a broad retrieval, and inspect the resulting diff before merging it.
Scratch Orgs, Sandboxes, and Developer Orgs in Salesforce DX
| Salesforce environment | Lifecycle | Typical Salesforce DX use |
|---|---|---|
| Scratch org | Temporary and created from configuration | Isolated feature development, package work, and automated testing |
| Sandbox | Persistent until refreshed or deleted | Integration testing, user acceptance testing, and work requiring copied configuration or data |
| Developer Edition org | Persistent | Learning, experimentation, and development where scratch-org management is unavailable |
Salesforce DX can be used with both scratch orgs and persistent orgs. Scratch orgs are a major DX capability, but they are not mandatory for every source-driven Salesforce project.
Salesforce DX Development Workflow with Git
- Pull the current project branch from the version control repository.
- Create a short-lived branch for the feature or fix.
- Create or select an isolated Salesforce development environment.
- Deploy the relevant project source to that environment.
- Implement the Apex, Lightning, object, permission, or configuration changes.
- Retrieve required metadata changes and review the local diff.
- Run Apex tests and project-specific quality checks.
- Commit only the intended source and configuration changes.
- Open a review request and resolve merge or metadata conflicts.
- Validate the approved revision against the target environment before deployment.
Do not commit passwords, access tokens, private keys, authentication URLs, customer data, or developer-specific configuration. Store deployment credentials in an approved secret-management system.
Apex Testing in a Salesforce DX Project
Automated Apex tests can be run from Salesforce CLI before a change is merged or deployed. The following command runs tests in the target org and displays human-readable results with code coverage:
sf apex run test \
--target-org MyScratchOrg \
--result-format human \
--code-coverage \
--wait 10A successful local test run does not guarantee a successful production deployment. The target org may contain different metadata, dependencies, permissions, data conditions, or tests. Use a validation process that reflects the destination environment.
Salesforce DX Debugging in Visual Studio Code
Salesforce Extensions for Visual Studio Code provide editing, project, test, and debugging support for Salesforce development. Developers can inspect Apex logs, run tests, execute anonymous Apex, and use supported debugger features.
Apex Replay Debugger replays a debug log locally so that a developer can inspect the recorded execution around configured checkpoints. It does not pause the original server transaction in real time. Other interactive debugging capabilities can have separate org, permission, and licensing requirements, so check the current Salesforce documentation for the intended environment.
Salesforce DX Continuous Integration and Deployment
A continuous integration pipeline can use Salesforce CLI to validate every proposed source change. A typical pipeline authenticates to a controlled environment, deploys or validates the selected metadata, runs Apex tests, records results, and prevents merging when required checks fail.
- Pin or control CLI and dependency versions used by the build.
- Use non-interactive authentication designed for automation.
- Keep credentials and keys outside the repository.
- Validate the same source revision that will be released.
- Record test, validation, and deployment results.
- Define how partial failures and post-deployment steps are handled.
Benefits and Limits of Salesforce DX
| Salesforce DX benefit | Practical limitation |
|---|---|
| Source changes can be reviewed and versioned. | Teams must agree on repository structure, branching, and metadata ownership. |
| Scratch orgs support isolated and repeatable environments. | They are temporary, subject to limits, and may not reproduce every production data condition. |
| CLI commands support automation. | Authentication, dependencies, error handling, and target selection must be managed carefully. |
| Automated tests can run during integration. | Test quality and environment differences still affect release confidence. |
| Modular package directories can organize source. | Existing org metadata may require analysis and refactoring before it is modular. |
Salesforce DX Setup References
- Salesforce Developer Experience resources
- Salesforce DX Developer Guide
- Trailhead Salesforce DX environment setup
Salesforce DX Editorial QA Checklist
- Confirm that new command examples use the current
sfcommand structure. - Verify that every CLI command identifies the intended org through an alias or configured default.
- Check that scratch-org features and settings match the metadata being tested.
- Confirm that retrieved metadata has been reviewed before it is committed.
- Verify that Apex tests cover the changed behavior and run in an appropriate validation org.
- Ensure that authentication material and org data are excluded from version control.
Salesforce DX Frequently Asked Questions
What is Salesforce DX?
Salesforce DX is a collection of tools and development practices for source-driven Salesforce delivery. It includes Salesforce CLI, DX project format, version control workflows, scratch orgs, testing, packaging options, and automation.
Is Salesforce DX the same as Salesforce CLI?
No. Salesforce CLI is a command-line tool used within Salesforce DX workflows. Salesforce DX also covers project structure, source control, environments, testing, collaboration, packaging, and delivery practices.
Does Salesforce DX require a scratch org?
No. Scratch orgs are designed for Salesforce DX, but developers can also use sandboxes, Developer Edition orgs, and other supported environments in a source-driven workflow.
What is the difference between a Dev Hub and a scratch org?
A Dev Hub provides the management capability used to create and administer scratch orgs. A scratch org is the temporary development or testing environment created through that Dev Hub.
What is the source of truth in Salesforce DX?
In a source-driven Salesforce DX workflow, the reviewed project revision stored in version control is the shared source of truth. Changes made directly in an org must be retrieved, reviewed, and committed if they are intended to remain part of the application.
Continue Learning Salesforce DX
In the following Salesforce tutorials, we cover how to enable developer hub in your Salesforce organisation, Installing Salesforce Developer Experience CLI and different Salesforce DX commands.