Getting started with Salesforce DX – Salesforce Developer Experience

Introduction and basics of Salesforce Developer Experience (Salesforce DX) with source code and Video tutorials

Salesforce Developer Experience - SFDX

Important : At time of writing this post, Salesforce DX is in pilot phase. Mostly any product in Salesforce goes from Pilot to Beta and then Generally available. There is no guarantee that if this product is released, it would work like exactly same as written in this post.

If we already have Salesforce Metadata API, IDE and other tools then why do we need one more tool like Salesforce DX ?

In tools like Changeset, Metadata API or IDE, source of truth is Sandbox. Although we can setup process and continuous integration (CI) to use some source code management (SCM) like Git or SVN. However these kind of setup takes time, expertise and lot of effort.

Salesforce DX not only solves above problem but

  • Ability to consider SCM as source of truth
  • Use any favorite IDE or any SCM
  • Powerful CLI to help minimizing complexity of setting up CI
  • Updated IDE to support Salesforce DX if you are not comfortable with CLI
  • and most important, spin off Scratch Orgs within minutes through script to quickly work on POC or package based development

What are scratch Orgs ?

Salesforce DX can be enabled for any Salesforce instance and they are known as Developer Hub. One Developer Hub can have multiple Scratch Orgs. Scratch Orgs are temporary Salesforce org which can be created quickly and metadata can be deployed from SCM. These kind of Orgs can be used by developers to perform quick proof of concept or build and test packages. Once package is build and saved back on SCM, scratch org can be destroyed easily.

If we already have developer orgs or sandboxes, why do we need scratch orgs ?

Because of compliance of most of clients, we cannot move their code to developer org to perform some POC or package development, so developer org is out of questions anyway.

Now, lets focus on Sandboxes. Use of sandboxes are mostly for end to end testing, integration testing, UAT or training. Sandboxes mostly represents either replica of production or future state of production which might be undergoing through User acceptance testing (UAT). When we refresh Sandbox, we don’t get options on which metadata needs to be copied. Assume situation, there is defect on production and we need to go back to time and check how system was behaving previously. Typical rollback scenario for sandboxes. We might have metadata stored somewhere, but we need to perform many iterations of destructive.xml to delete components from Sandbox. In this case, we can quickly spin off scratch org from source code and perform analysis of historical code.

This is just one example, there are many scenario and specifically for appexchange development companies.

I think, we had lots of talk and ready to roll now.

Setting up Salesforce DX

Install Heroku CLI and then run below command

heroku plugins:install salesforcedx

Other way to install SalesforceDX during pilot is to installer from here (Currently this URL is working however its location is not official). Once downloaded, install it. After installation make sure git command is working from command line.

In Salesforce DX, source of truth is source control. so we need a repository for demo. For this blog post, let’s consider this repository. Run below command to clone this repository

git clone
cd sfdx-simple

Authorize Salesforce DX to login to Developer Hub Org

Below command will set org as default Developer Hub Org and will set its alias as my-devhub-org. It will open Salesforce login page in default browser for OAuth flow, where we need to login to Developer Hub org and authorize Salesforce DX.

sfdx force:auth:web:login --setdefaultdevhubusername --setalias my-devhub-org

Creating Scratch Org

To create a scratch org in Salesforce DX, we need to have workspace-scratch-def.json . Best place is to place it in config folder. This file already exists in Git repository we cloned initial however we would need to update it with our FirstName, lastName, Email and Org preferences. All supported preferences are listed here in Metadata documentation. Below is sample of file


"Company": "Shivasoft",
"Country": "US",
"LastName": "Zaa",
"Email": "",
"Edition": "Developer",
"OrgPreferences" : {
"S1DesktopEnabled" : true

Edition of Org can be Professional, developer or enterprise.

Once workspace-scratch-def.json created in config folder, run below command to create a scratch org. New scratch would be named as jitendra2_scratch and it can be configured by passing parameter to –setalias

Note : At a time of writing this post, scratch orgs auto deleted after 7 days however it may change when product goes GA.

sfdx force:org:create --setdefaultusername -f config/workspace-scratch-def.json --setalias jitendra2_scratch

Moving code to Scratch Org

To move code, we need to define sfdx-workspace.json which contains path of source code needed to be pushed. Below is sample file

simple sfdx-workspace.json

  "PackageDirectories": [
      "Path": "force-app"
  "Namespace": "",
  "SourceApiVersion": "39.0"

sfdx-workspace.json with some more options

"Namespace" : "AcmeIncExample",
"SfdcLoginUrl" : "",
"SourceApiVersion": "39.0"
"PackageDirectories" : [
{ "Path" : "helloWorld", "Default": true},
{ "Path" : "unpackaged" },
{ "Path" : "utils" }

Run below command to push metadata to default scratch org

sfdx force:source:push
sfdx force:source:push --targetusername

Get metadata changes from Scratch Org or Pull changes

We can also get metadata changes done in scratch Org either from UI or deployment. It will only pull if metadata changes, not the whole Org.

sfdx force:source:pull
sfdx force:source:pull -u org_alias

Getting list of all existing Orgs

Before creating scratch org, you may want to know about the existing orgs and their aliases. We can run below command

sfdx force:org:list

Open Salesforce Org from sfdx

Below command can be used to open Org from sfdx command line

sfdx force:org:open
sfdx force:org:open -u org_alias

Running Test classes using Salesforce DX

To run test classes using Salesforce DX , use below command

sfdx force:apex:test:run

Above command will return job Id, use that ID and run next command for status

sfdx force:apex:test:report -i JOBID_FROM_ABOVE_COMMAND

Setting up log Levels

Salesforce DX logs are generated at USER_Home_DIR/.sfdx/sfdx.log. We can set it either with each command or globally. By default only Error logs are recorded but we can change log level. To set log level with each command, we can use –loglevel DEBUG. To set log level globally we can use

//Or in unix

Currently below log levels are supported

  1. ERROR
  2. WARN
  3. INFO
  4. DEBUG
  5. TRACE

Creating skeleton workspace

We can automatically generate skeleton workspace using CLI which will create folder structure and json files with default value.

sfdx force:workspace:create --workspacename mywork


sfdx force:workspace:create --workspacename mywork --defaultpackagedir myapp

Above command will create below folder structure

Salesforce DX Skeleton Workspace
Salesforce DX Skeleton Workspace

Password for scratch Orgs

When we create a scratch org using sfdx CLI, it does not display password and uses OAuth internally to communicate with scratch org. If we need to login to scratch org from non sfdx CLI, then we would need to generate a password. Below command can be used to generate password.

sfdx force:user:password:generate

Message :

Successfully set the password "26y271a" for user You can see the password again by running "force:org:describe".

If we want to see password in future, then use below command


Video, coming soon

Related posts