SFDX
SFDX is the acronym for Salesforce Developer Experience.

Salesforce Developer Experience
SFDX represents a modern approach to Salesforce development that emphasizes source-driven development, continuous integration, and version control. This glossary explains the key terminology and concepts that form the foundation of SFDX.
Core Concepts
Scratch Org
A scratch org functions as a temporary, configurable Salesforce environment that lasts up to 30 days. Think of it as a disposable development environment where you can experiment with new features, test configurations, and develop code without affecting your production organization. When you create a scratch org, you’re essentially getting a fresh, empty Salesforce instance that you can customize according to your needs.
Example command to create a scratch org:
sfdx force:org:create -f config/project-scratch-def.json -a DevOrg1 -d 30
Dev Hub
The Dev Hub serves as the central control point for creating and managing scratch orgs. It’s like a command center that keeps track of all your development environments. When you enable Dev Hub in a production org or business org, it gains the ability to spawn and oversee scratch orgs. Think of it as a parent organization that can create and manage child development environments.
Source Format
Source format refers to the decomposed structure of Salesforce metadata when working with SFDX. Unlike the traditional metadata format, where components are bundled together, the source format breaks down metadata into smaller, more manageable files. This approach makes version control more effective and helps prevent conflicts when multiple developers work on the same components.
Example source format structure:
force-app/
main/
default/
classes/
AccountService.cls
AccountService.cls-meta.xml
objects/
Account/
fields/
CustomField__c.field-meta.xml
Package Development Model
The package development model represents a modular approach to building Salesforce applications. Instead of developing directly in an org, you create packages that contain specific functionality. These packages can be installed in different orgs, making your development more portable and reusable. Think of packages as self-contained units of functionality that can be distributed and installed independently.
Project Configuration
SFDX projects use specific configuration files to maintain consistency across different development environments:
sfdx-project.json: The project’s main configuration file that defines:
{
"packageDirectories": [
{
"path": "force-app",
"default": true,
"package": "MyPackage",
"versionName": "Version 1.0",
"versionNumber": "1.0.0.NEXT"
}
],
"namespace": "",
"sfdcLoginUrl": "https://login.salesforce.com",
"sourceApiVersion": "57.0"
}
project-scratch-def.json: Defines the shape of scratch orgs:
{
"orgName": "Development Org",
"edition": "Developer",
"features": ["EnableSetPasswordInApi"],
"settings": {
"lightningExperienceSettings": {
"enableS1DesktopEnabled": true
}
}
}
Common Commands and Their Purposes
Authentication Commands
These commands help you connect to your Salesforce orgs:
- force:auth:web:login: Opens a web browser for interactive login. This command initiates the OAuth flow, allowing you to authenticate with your Salesforce organization securely.
sfdx force:auth:web:login -a ProductionOrg
Development Commands
Commands used during the development process:
- force:source:push: Uploads local source to a scratch org. Think of this as synchronizing your local changes with your development environment.
sfdx force:source:push -u DevOrg1
- force:source:pull: Downloads changes from a scratch org. This retrieves any changes made directly in the scratch org, keeping your local source current.
sfdx force:source:pull -u DevOrg1
Testing Commands
Commands for executing and managing tests:
- force:apex:test:run: Executes Apex tests. This command runs your Apex tests and provides detailed results about test coverage and failures.
sfdx force:apex:test:run -l RunLocalTests -c -r human
Environment Management
Sandboxes vs. Scratch Orgs
When developing on the Salesforce platform, choosing the right type of non-production environment is crucial for successful development and testing. Salesforce offers two primary options: Sandboxes and Scratch Orgs, each serving distinct purposes in the development lifecycle. Sandboxes function like copies of your production organization, maintaining all your customizations and, optionally, your data, making them ideal for testing changes in an environment that closely mirrors production.
Scratch Orgs, by contrast, are empty, temporary environments that you build from scratch according to defined specifications. This makes them perfect for new feature development and automated testing. Understanding each environment type’s strengths and appropriate use cases helps developers choose the right tool for their specific needs and create more efficient development workflows.
Sandboxes
Sandboxes are persistent environments that copy your production org’s metadata and (optionally) data, ideal for:
- User acceptance testing
- Integration testing
- Training environments
- Staging environments before production deployment
Scratch Org
Scratch orgs, by contrast, are empty, temporary environments that:
- Start fresh with each creation
- Can be quickly configured via source control
- Are ideal for development and automated testing
- Have a maximum lifespan of 30 days
Version Control Integration
SFDX projects are designed to work seamlessly with version control systems like Git. The source format makes it easier to:
- Track changes at a granular level
- Manage conflicts between developers
- Maintain a history of changes
- Support continuous integration/continuous deployment (CI/CD) pipelines
Best Practices
Project Structure
Organize your SFDX project with a clear structure:
my-project/
force-app/ # Main source directory
main/
default/ # Default package directory
config/ # Configuration files
scripts/ # Build and automation scripts
.forceignore # Files to ignore in deployment
sfdx-project.json # Project configuration
project-scratch-def.json # Scratch org definition
Development Workflow
- Create a feature branch from your main branch
- Create a scratch org for the feature development
- Develop and test in the scratch org
- Pull changes to your local project
- Commit changes to version control
- Create a pull request for code review
- Merge to the main branch after approval
SFDX represents a significant evolution in how Salesforce applications are developed and deployed. By understanding these concepts and terms, developers can better utilize the tools and practices that make modern Salesforce development more efficient and reliable. Remember that SFDX is continually evolving, and staying updated with the latest features and best practices is essential for successful development.
- Abbreviation: SFDX