Newer Version Available

This content describes an older version of this product. View Latest

Limitations for Salesforce DX

Here are some known issues you could run into while using Salesforce DX.

Salesforce CLI

Windows Defender Suspends CLI Installation
Description: When you are installing the Salesforce CLI on Windows, you see a Windows Defender warning. This message is expected because we updated the installer’s code signing certificate.
Windows Defender popup indicating that this app might put your PC at risk

Workaround: Click Run anyway to ignore this message.

Can’t Import Record Types Using the Salesforce CLI
Description: We don't support RecordType when running the data:tree:import command.

Workaround: None.

Stacktrace May Occur When Upgrading the CLI from 5.7.6 to 6.0
Description: When upgrading the Salesforce CLI from version 5.7.6 to 6.0 by running sfdx update, you could see a stacktrace instead of this successful completion message:
1sfdx update

2sfdx-cli: Updating plugins... done

Workaround: This glitch is temporary. Rerun sfdx update.

Limited Support for Shell Environments on Windows
Description: Salesforce CLI is tested on the Command Prompt (cmd.exe) and Powershell. There are known issues in the cygwin and Min-GW environments, and with Windows Subsystem for Linux (WSL). These environments might be tested and supported in a future release. For now, use a supported shell instead.

Workaround: None.

The force:apex:test:run Command Doesn’t Finish Executing
Description: In certain situations, the force:apex:test:run command doesn’t finish executing. Examples of these situations include a compile error in the Apex test or an Apex test triggering a pre-compile when another is in progress.

Workaround: Stop the command execution by typing control-C. If the command is part of a continuous integration (CI) job, try setting the environment variable SFDX_PRECOMPILE_DISABLE=true.

Dev Hub and Scratch Orgs

Salesforce CLI Sometimes Doesn’t Recognize Scratch Orgs with Communities
Description: Sometimes, but not in all cases, the Salesforce CLI doesn’t acknowledge the creation of scratch orgs with the Communities feature. You can’t open the scratch org using the CLI, even though the scratch org is listed in Dev Hub.

Workaround: You can try this workaround, although it doesn’t fix the issue in all cases. Delete the scratch org in Dev Hub, then create a new scratch org using the CLI. Deleting and recreating scratch orgs counts against your daily scratch org limits.

Error Occurs If You Pull a Community and Deploy It
Description: The error occurs because the scratch org doesn’t have the required guest license.

Workaround: In your scratch org definition file, if you specify the Communities feature, also specify the Sites feature.

Source Management

ERROR: No Results Found for force:source:status After Deleting a Custom Label
Description: The force:source:status command returns a No Results Found error after you delete a custom label in a scratch org.

Workaround: Option #1: Use this workaround if you have only one or two scratch orgs, and you can easily identify the affected scratch org by its generated username. In the Your DX project/.sfdx/org directory, delete only the folder of the affected scratch org.

Option #2: Use this workaround if you have several scratch orgs associated with your DX project, and you don’t know which scratch org’s local data to delete. Delete the Your DX project/.sfdx/org directory. This directory contains source tracking information for all scratch orgs related to the project. When you run the next source-tracking command for this or another scratch org (source:push, source:pull, or source:status), the CLI reconstructs the source tracking information for that org.

After you delete the directory (after option #1 or option #2), run force:source:status again.

Can’t Use Apex Editor in Setup to Create or Update Triggers in Scratch Orgs
Description: An error occurs if you use the Apex editor in Setup to create or update a trigger in a scratch org, then run source:pull or source:status.

Workaround: Use the Dev Console, Visual Studio Code, or another external editor built on top of Tooling API or Metadata API.

ERROR: Entity of type 'RecordType' named 'Account.PersonAccount' cannot be found
Description: Although you can turn on Person Accounts in your scratch org by adding the feature to your scratch org definition, running source:push or source:pull results in an error,

Workaround: None.

Deployment Fails If History Tracking Is Enabled for Custom Lookup Fields with Lookup Filters
Description: When deploying metadata, you see this error message when the lookup filter refers to a field with tracking enabled for that custom object in the same deployment transaction.
1<unknown> duplicates value on record with id: <unknown> error
Workaround: Try one of these options:
  • Deploy both the objects in different transactions to avoid the error.
  • Remove the History Tracking on the custom field and then deploy. Once the deployment is completed, you can enable history tracking on the custom field as part of post-deployment step.
force:source:convert Doesn’t Add Post-Install Scripts to package.xml
Description: If you run force:source:convert, package.xml does not include the post install script.
Workaround: Choose one of these methods to fix this issue:
  • Manually add the <postInstallClass> element to the package.xml in the metadata directory that force:source:convert produces
  • Manually add the element to the package in the release org or org to which you are deploying the package.
Must Manually Enable Feed Tracking in a Custom Object's Metadata File
Description: If you enable feed tracking on a custom object, then run force:source:pull, feed tracking doesn't get enabled.

Workaround: In your Salesforce DX project, manually enable feed tracking on the custom object in its metadata file (-meta.xml) by adding <enableFeeds>true</enableFeeds>.

Unable to Push Lookup Filters to a Scratch Org
Description: When you execute the force:source:push command to push the source of a relationship field that has a lookup filter, you sometimes get the following error:

duplicate value found: <unknown> duplicates value on record with id: <unknown> at line num, col num.

Workaround: None.

First-Generation Packaging

When You Install a Package in a Scratch Org, No Tests Are Performed
Description: If you include tests as part of your continuous integration process, those tests don’t run when you install a package in a scratch org.

Workaround: You can manually execute tests after the package is installed.

New Terminology in CLI for Managed Package Password
Description: When you use the CLI to add an installation key to a package version or to install a key-protected package version, the parameter name of the key is --installationkey. When you view a managed package version in the Salesforce user interface, the same package attribute is called “Password”. In the API, the corresponding field name, “password”, is unchanged.

Workaround: None. The Password field name in the user interface will be changed in a future release.

Second-Generation Packaging

Second-Generation Packages Cannot Depend on Packages Requiring an Installation Key
Description: When creating a second-generation package version, we don’t support package dependencies (first-generation or second-generation) that require an installation key.

Workaround: None. We plan to support this functionality soon in a future release.

API Version Must be 41.0 or Later
Description: API versions before 41.0 aren’t supported for second-generation packages.

Workaround: Before you create a second-generation package, verify that you’ve set the sourceApiVersion in sfdx-project.json to 41.0 or later.

Unable to Specify a Patch Version
Description: The four-part package version number includes a patch segment, defined as major.minor.patch.build. However, you can’t create a patch for a second-generation package. Package creation fails if you set a patch number in the package descriptor. Stay tuned for patch versions in an upcoming release.

Workaround: Always set the patch segment of the version number, to 0. For example, 1.2.0.1 is valid but 1.2.1.1 is not.

Protected Custom Metadata and Custom Settings are Visible to Developers in a Scratch Org If Installed Packages Share a Namespace
Description: Use caution when you store secrets in your second-generation packages using protected custom metadata or protected custom settings. You can create multiple second-generation packages with the same namespace. However, when you install these packages in a scratch org, these secrets are visible to any of your developers that are working in a scratch org with a shared namespace. In the future, we might add a “package-protected” keyword to prevent access to package secrets in these situations.

Workaround: None.