Salesforce CLI | sf Command Guide | SalesforceTutorial

Salesforce CLI Guide for Admins and Developers

Salesforce CLI is the supported command-line tool for Salesforce DX work such as org login, project creation, metadata retrieve and deploy, Apex tests, data commands, and release automation. In 2026, new work should use the sf executable and sf-style commands; older sfdx-style commands are deprecated in Salesforce documentation.

Use Salesforce CLI when the Setup UI is too slow, when the same release step must run in multiple orgs, or when a team wants metadata reviewed in Git before it reaches a sandbox or production. It helps admins move Flow and object configuration, helps developers run tests and deployments, and helps architects standardize how org changes move through environments.

What is Salesforce CLI and when should you use it?

The CLI is a terminal-based interface for Salesforce development and administration. Instead of clicking through Setup, you type commands that authenticate to an org, read metadata, deploy files, run tests, query records, or create development environments.

The official Salesforce developer site describes the tool as a single command-line interface for Salesforce DX features. The practical meaning is simple: Salesforce CLI gives teams a repeatable way to work with metadata and orgs. A command in a release script behaves the same way for every developer, every sandbox, and every CI job when the inputs are controlled.

In enterprise orgs, Salesforce CLI is rarely used alone. It normally sits with a Git repository, pull request process, sandbox strategy, Apex test policy, and a release calendar. The tool does not decide whether a change is safe. It makes the chosen process repeatable.

Salesforce CLI setup for 2026

Install Salesforce CLI from the official Salesforce Developers download page or through npm. The download page provides installers for macOS, Windows, and Linux, while npm is useful for build agents and machines where you manage Node.js packages directly. See the official Salesforce CLI page at https://developer.salesforce.com/tools/salesforcecli.

Sfdx cli download vs current Salesforce CLI installer

Many older tutorials and searches still say sfdx cli download. The safer 2026 interpretation is: download the current Salesforce CLI and use the sf command. Salesforce documentation states that sfdx-style commands are deprecated and provides migration guidance to sf-style commands. Keep old scripts working only long enough to migrate them.

# Install with npm when you manage CLI tools through Node.js
npm install @salesforce/cli --global

# Confirm that the sf executable is available
sf --version

# Update the installed CLI
sf update

For a laptop used by an admin or developer, the operating-system installer is usually simpler. For a CI runner, npm or a prepared build image is easier to reproduce. Avoid mixing installer and npm installations on the same machine unless you know which executable appears first in the PATH.

Sf cli checks after installation

After installation, run a small set of commands before you connect to an org. These checks confirm that the sf cli binary is on the PATH, that command help loads, and that your version is current enough for your project.

sf --version
sf --help
sf commands
sf update

If the terminal returns “command found” or “not recognized,” close and reopen the terminal. On Windows, also check whether the installer added the Salesforce CLI directory to the PATH. On macOS or Linux, confirm that your shell startup files are not overriding PATH with an older Node.js or CLI location.

Sf command basics: syntax, flags, and help

An sf command reads from left to right: executable, topic, action, flags, and flag values. The command reference is the source of truth for exact flags, because names can change during command migrations. Keep the official command reference bookmarked at https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_top.htm.

Sf command structure

sf <topic> <action> <subaction> --flag value --boolean-flag

For example, this command opens a browser login flow, stores the org under an alias, and makes the org the default target for commands in the current context.

sf org login web --alias DevSandbox --set-default

Long flags such as --target-org make scripts easier to read. Short flags save typing in a terminal, but they are harder to review in a pull request. For release scripts, prefer long flags and include --target-org even when a default org is set.

Aliases and target orgs in sf cli

Aliases reduce the risk of deploying to the wrong org. Use names such as DevSandbox, UAT, FullCopy, and Prod instead of usernames that are hard to read. Before every deployment, check the authenticated org list.

sf org list
sf org display --target-org UAT
sf config get target-org

Production aliases should be clear and boring. Do not call production default, test, or main. In production release scripts, pass the production alias directly and require a validation step before the deploy step.

How to authenticate orgs with Salesforce CLI

The CLI can authenticate to many orgs and store local authorization details. For a developer laptop, web login is the common starting point. For CI/CD, use an authentication method that does not require a browser, such as JWT-based auth with a connected app and certificate.

Login to a sandbox with sf command

sf org login web \
  --instance-url https://test.salesforce.com \
  --alias UAT \
  --set-default

Use https://test.salesforce.com for a sandbox login unless your org requires a My Domain login URL. Use your My Domain URL when SSO, login policies, or sandbox routing require it.

Login to a Dev Hub for scratch org work

sf org login web \
  --alias DevHub \
  --set-default-dev-hub

Do not set a sandbox as the default Dev Hub by accident. A Dev Hub is the org used to create and manage scratch orgs. A sandbox can be a target for development and testing, but it is not automatically the correct Dev Hub for your team.

Open an authenticated org

sf org open --target-org UAT

This command is useful during troubleshooting because it confirms that your local alias points to the org you expect. In production environments, use it carefully and avoid making manual changes that bypass your release process.

How to retrieve and deploy metadata with Salesforce CLI

The CLI works best when metadata lives in a Salesforce DX project. The project contains sfdx-project.json, source folders such as force-app, and the files you want to retrieve, review, test, and deploy.

sf project generate --name case-operations
cd case-operations

Set sourceApiVersion in sfdx-project.json to a version supported by your target org. For a Summer ’26 sandbox, API v67.0 is a common target, but the right value is the version your org and release plan support. Salesforce documents that CLI deploy and retrieve behavior uses API version settings, so do not copy an old project file without checking it.

{
  "packageDirectories": [
    {
      "path": "force-app",
      "default": true
    }
  ],
  "name": "case-operations",
  "namespace": "",
  "sourceApiVersion": "67.0"
}

Retrieve selected metadata

Retrieve only the metadata needed for the work item. This keeps pull requests smaller and reduces the chance of moving unrelated changes.

sf project retrieve start \
  --metadata "Flow:Case_Intake" \
  --metadata "CustomField:Case.Internal_Reason__c" \
  --target-org UAT

After retrieval, review the changed XML files in Git. For Flow, check versions, subflow dependencies, custom fields, permission set access, and record-triggered entry conditions. For objects and fields, check whether profiles or permission sets must be deployed with the field metadata.

Deploy with tests and wait time

Use a validation or deploy command with an explicit test level. Production deployments must satisfy Salesforce test requirements, including at least 75% Apex code coverage across the org and successful required tests. The CLI starts the deployment, but Salesforce enforces the same Metadata API deployment rules that apply outside the CLI.

sf project deploy start \
  --source-dir force-app \
  --target-org QA \
  --test-level RunLocalTests \
  --wait 30

For production, validate first, review the result, then quick deploy when your release process allows it.

sf project deploy validate \
  --source-dir force-app \
  --target-org Prod \
  --test-level RunSpecifiedTests \
  --tests CaseIntakeServiceTest \
  --wait 60

sf project deploy quick \
  --job-id 0AfXXXXXXXXXXXXXXX \
  --target-org Prod

In enterprise orgs, do not use RunSpecifiedTests only because it is faster. Use it when the change qualifies and your release policy defines the expected test classes. For broad platform changes, sharing changes, trigger framework updates, or managed package interactions, RunLocalTests gives better coverage of org risk.

How to run tests, Apex, and SOQL with sf cli

The sf cli is not limited to deployment. It can run Apex tests, execute anonymous Apex from a file, and query records. These commands are useful for release checks, troubleshooting, and repeatable admin tasks.

Run Apex tests from the terminal

sf apex run test \
  --target-org QA \
  --test-level RunSpecifiedTests \
  --tests CaseIntakeServiceTest \
  --result-format human \
  --code-coverage \
  --wait 20

For CI, use --result-format json and store the output as a build artifact. A failed test should stop the pipeline. Do not ignore test failures because a deployment command returned a job id; read the final status before continuing.

Run anonymous Apex from a file

sf apex run \
  --target-org DevSandbox \
  --file scripts/recalculate-case-priority.apex

// scripts/recalculate-case-priority.apex
List<Case> casesToUpdate = [
    SELECT Id, Priority, Status
    FROM Case
    WHERE Status = 'New'
    LIMIT 100
];

for (Case c : casesToUpdate) {
    c.Priority = 'Medium';
}

if (!casesToUpdate.isEmpty()) {
    update casesToUpdate;
}

This Apex sample uses one SOQL query and one DML statement outside the loop. That pattern matters because Salesforce governor limits still apply. The CLI does not bypass Apex limits, CRUD/FLS design, sharing behavior, validation rules, duplicate rules, or triggers.

Run a SOQL query with sf command

sf data query \
  --target-org UAT \
  --query "SELECT Id, Name, Industry FROM Account WHERE Industry = 'Manufacturing' LIMIT 10"

Query only the fields you need and include selective filters when querying large objects. For exports that involve many records or scheduled migrations, compare this command with Salesforce Data Loader for bulk data jobs.

How to move sample data without breaking relationships

CLI data tree commands work well for small sets of related records, such as Account and Contact seed data for a scratch org or development sandbox. They are not a replacement for a full data migration strategy.

sf data export tree \
  --target-org UAT \
  --query "SELECT Name, (SELECT FirstName, LastName, Email FROM Contacts) FROM Account WHERE CreatedDate = LAST_N_DAYS:30" \
  --plan \
  --output-dir data

sf data import tree \
  --target-org DevSandbox \
  --plan data/Account-Contact-plan.json

Use this pattern when the data set is small and relationship references matter. For high-volume loads, use Data Loader, Bulk API, or a controlled ETL process. Also check field-level security, required fields, validation rules, duplicate rules, and automation that can fire during import.

How to use Salesforce CLI in CI/CD pipelines

In CI/CD, the CLI should run without browser prompts. A typical pipeline installs the CLI, authenticates with a connected app, validates the deployment, runs tests, and stores JSON output. The exact syntax depends on your authentication design and secret store.

#!/usr/bin/env bash
set -euo pipefail

npm install @salesforce/cli --global
sf --version

sf org login jwt \
  --client-id "$SF_CLIENT_ID" \
  --jwt-key-file "$SF_JWT_KEY_FILE" \
  --username "$SF_USERNAME" \
  --alias ci-target

sf project deploy validate \
  --source-dir force-app \
  --target-org ci-target \
  --test-level RunLocalTests \
  --wait 60 \
  --json > deploy-validation.json

Store private keys and client ids in your CI secret manager, not in the repository. Rotate certificates according to your security policy. When a deployment fails, keep the JSON result so developers can inspect component failures, test failures, and deployment ids.

Salesforce command center vs Salesforce CLI

The search phrase salesforce command center can mean a different Salesforce feature, not Salesforce CLI. For example, Salesforce Help documents Command Center for Service for supervisors who monitor Omni-Channel workloads. That is a Lightning app experience for operations monitoring. Salesforce CLI is a terminal tool for metadata, org access, data commands, tests, packages, and automation.

If your requirement is “see live service workload,” research Command Center for Service. If your requirement is “run a repeatable command to deploy Flow metadata,” use Salesforce CLI. The two can support the same operations team, but they solve different problems.

Best practices for Salesforce CLI in enterprise orgs

• Use sf-style commands for new work. Keep legacy sfdx commands only while you migrate scripts and documentation.
• Name aliases clearly. Use DevSandbox, UAT, and Prod. Check sf org display before deployment.
• Do not deploy straight from an admin laptop to production. Use Git, pull requests, validation deployments, and release approvals.
• Pin your release expectations. Review sourceApiVersion, command flags, package versions, and plugin versions before a release.
• Run tests as part of the command flow. Treat failed tests as release blockers unless the failure is triaged and documented.
• Respect Salesforce security. CLI deployment does not prove that runtime access is correct. Review permission sets, sharing, CRUD/FLS, and Apex sharing declarations.
• Use JSON output for automation. Scripts should parse machine-readable output rather than terminal text written for humans.
• Review plugins before installing them. Salesforce CLI supports plugins, but a plugin runs code on the machine where it is installed.

Common errors with Salesforce CLI

Related Salesforce CLI resources

Use these related SalesforceTutorial resources when you connect CLI work to a broader implementation:

• Salesforce release updates and API version planning
• LWC development with Salesforce DX projects
• Data Loader for Salesforce data migration
• Salesforce reports for post-deployment checks
• Salesforce AI and Agentforce implementation planning

For official reference, use the Salesforce CLI Setup Guide, the Salesforce CLI Command Reference, and the Trailhead Salesforce DX tools setup unit.

Frequently Asked Questions