Get Started with Salesforce CLI Unification

How Does sf Improve on sfdx?

sf is similar to sfdx in that it's a command-line interface that simplifies Salesforce development and build automation. But it also includes some key new features and design changes.

• The sf command hierarchy reflects a typical developer's workflow rather than Salesforce brands, products, or features.

  For example, the top-level topics include configuring the CLI (sf config), logging into environments (sf login), deploying and retrieving (sf deploy and sf retrieve), and managing environments (sf env).

  As sf grows and embraces other Salesforce clouds, it will include their commands in this workflow-focused hierarchy instead of each product having its own command hierarchy. Because sf creates consistency across all these commands, it's easier and more intuitive to use, even when developing on a new cloud.

• sf provides interactive commands that actively prompt you for required information rather than passively accepting flag values. Now you don't have to remember all the flag names or which are required, which in turn reduces errors. For example, sf deploy prompts you for deployment environment and artifacts, level of testing, and so on.

  Each interactive command has an environment-specific command for use in automated scripts. For example, sf deploy metadata has flags to specify the org you're deploying to, the metadata location, and so on.

• Improved --help output:
  • We’ve enhanced the command-line help to include additional information and examples. As a result, the help can get long, so we’ve also changed the behavior of the flags:
    • -h: Displays a subset of the full help: short command and flag descriptions and command usage. Great for quick reference information.
    • --help: Displays the -h content plus longer command and flag descriptions, examples, and the configuration and environment variables that affect the command.
  • The long --help output contains new CONFIGURATION VARIABLES and ENVIRONMENT VARIABLES sections that list the configuration and environment variables that affect the command.
  • The short flag descriptions are grouped into logical groups for easier reading, which is especially useful when a command has many flags. All examples have brief explanations.
  • The long flag descriptions are displayed at the end of the --help output. In sfdx, the long flag descriptions don’t display in the --help output at all. They’re documented only in the Salesforce CLI Command Reference.
• The command output has been standardized and improved for readability.

Look Out: Differences Between sf and sfdx

• The commands to deploy and retrieve org metadata (sf deploy|retrieve metadata) don't yet include source-tracking functionality. If you want to use source-tracking in scratch orgs or sandboxes, keep using the sfdx force:source:push|pull commands for now.
• sf uses spaces between topics, commands, and subcommands rather than colons. For example, the sf command to get a configuration variable is sf config get; in sfdx, the command is sfdx config:get.
• Where appropriate, we've renamed sfdx flags in sf to include dashes in its name for better readability. For example, --apiversion in sfdx is now --api-version in sf.
• In sf, you have two ways to use flags that take multiple values:
  • Specify the flag multiple times, with each flag taking a different single value. For example:
    1sf deploy metadata --metadata ApexClass \
    2                   --metadata CustomObject \
    3                   --metadata AnotherCustomObject
    4                   --metadata "My Apex Class"

  • Specify the flag one time, but separate all the values with a space:
    1sf deploy metadata --metadata ApexClass CustomObject AnotherCustomObject "My Apex Class"

  In sfdx you specify the flag one time and separate the values with commas:

  1sfdx force:source:deploy --metadata ApexClass,CustomObject,AnotherCustomObject

• While equivalent sf and sfdx commands, such as sf config set and sfdx config:set, are interoperable and aware of each other, they produce different JSON output.

New and Changed Terminology

A quick word about these sf terms:

• Environments: A general term for the thing you use the CLI to interact with, such as the org to which you deploy metadata. We currently support Salesforce orgs and compute environments to which you deploy Salesforce Functions.

  Commands for managing environments are grouped under the sf env topic, such as sf env list, which lists all the environments you've created or logged into.

• Logging in: In sf you log into an environment, which authorizes the CLI to run other commands that interact with that environment. In sfdx we use the term authorize.
• Flags: In sf we consistently use the term flag in the documentation, such as the --json flag of a command. In sfdx we use the terms parameter, flag, and option in the documentation, sometimes interchangeably.
• Configuration variables: In sf, you use configuration variables to configure aspects of the CLI. In sfdx we call them configuration values.
• Target: In sf, we use the term target when referring to an environment, such as the target-org or target-dev-hub configuration variables or --target-env flag. We’re moving away from the terms defaultusername and defaultdevhubusername, which we use in sfdx.