Salesforce CLI Command Reference

Clouds with binary code floating aboveCloud with binary code floating above

No Results

Search Tips:

  • Please consider misspellings
  • Try different search keywords
Salesforce CLI Command Reference
Release Notes
sf
Salesforce Functions (Retired)
sfdx (Deprecated)
Migrate sfdx-Style Commands to Their sf-Style Equivalents
force:source:* and force:mdapi:* Commands Migration
force:org:* Commands Migration
force:data:bulk:* Commands Migration
Configuration and Environment Variable Names Migration
Source Tracking in New sf-Style Commands
Mapping sfdx Commands to Their sf Equivalents
Mapping sf Commands to Their sfdx Equivalents
CLI Deprecation Policy
Discover Salesforce Plugins
PDF

Source Tracking in New sf-Style Commands

Source tracking in the new sf-style commands works basically the same as in the sfdx-style commands, but with a few small differences outlined in this topic.

If you’re still using version 7 of the sfdx executable of Salesforce CLI (also referred to as sfdx (v7)), move to version 2 of the sf executable (sf (v2)). See Move from sfdx (v7) to sf (v2) for details.

Note

These sf-style commands support source tracking.

  • project deploy start
  • project delete source
  • project retrieve start

The sf-style commands encapsulate the functionality of these six deprecated sfdx-style commands.

  • force:source:push
  • force:source:pull
  • force:source:deploy
  • force:source:retrieve
  • force:mdapi:deploy
  • force:mdapi:retrieve

Let’s start with deploying. The first time you run project deploy start on a scratch or sandbox org that allows source tracking, the command deploys all the source files from your local project. But when you next run the command, it deploys only the files that changed locally. If you use one of the flags to narrow the deploy list, --source-dir, --metadata, or --manifest, then the command deploys only the changed files in the specified directory, metadata, or manifest. If you don’t specify any of the flags, then the command deploys all changes in the project, similar to how the sfdx-style command force:source:push works.

If you run project retrieve start on a newly created org, nothing happens because there are no changes to track yet. When you next run the command, any changes in the org are retrieved. These changes include updates from other users who connect to the org, not just your changes. If you don’t specify --source-dir, --metadata, or --manifest, then all changes in the org are retrieved, just like the sfdx-style command force:source:pull.

If one of these commands detects a conflict in the files you’re about to deploy or retrieve, the command displays the conflicts. To force the deployment or retrieval of the changes, use the --ignore-conflicts flag. This flag is similar to the --forceoverwrite flag of many of the force:source commands. For example:

sf project deploy start --source-dir force-app --ignore-conflicts

Determine If Your Org Allows Source Tracking

Source tracking works only if your target org allows it. Don’t worry, you can still deploy or retrieve metadata to and from an org without source tracking. But the commands don’t check for conflicts, and you must specify what you want to deploy or retrieve using an appropriate flag, such as --source-dir.

Here’s how to determine whether your org allows source tracking.

  • For Developer Edition orgs, production orgs, Partial Copy sandboxes, and Full sandboxes, source tracking isn’t available.
  • For Developer and Developer Pro sandboxes:
    • Source tracking is enabled if their associated production org has been enabled for source tracking.
    • Source tracking is possible when you create the sandbox with the --no-track-source flag of the org create sandbox command. For example:
      sf org create sandbox --definition-file config/dev-sandbox-def.json --target-org prodOrg --no-track-source
  • Scratch orgs have source tracking by default.
    • You can opt out of source tracking when you create the scratch org with the --no-track-source flag of the org create scratch command. This flag affects only your local configuration, not the scratch org itself. Salesforce CLI sets a local configuration option trackSource: false as part of your authorization information to the org. If you log out of the scratch org and then log back in again, source tracking is enabled again by default. Here’s how to create a scratch org with source tracking disabled.
      sf org create scratch --target-dev-hub=MyHub --definition-file config/project-scratch-def.json --no-track-source

You can use the org disable tracking or org enable tracking commands to disable or enable source tracking on an existing org.

Tip