Salesforce DX Developer Guide

How Salesforce Developer Experience Changes the Way You Work
Project Setup
Authorization
Scratch Orgs
Development
Build and Release Your App
Develop Packages (Beta)
Continuous Integration
Troubleshoot Salesforce DX
Limitations for Salesforce DX
PDF

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

Upgrade to High Sierra Breaks Salesforce CLI Installation
Description: After upgrading Mac OS X to High Sierra, the CLI installation breaks for Mac users that have used the .pkg installer to install the CLI.

Workaround: Before you uninstall and reinstall the CLI, see if this fix works from one of our amazing Salesforce architects. See this blog for details.

If that doesn’t work, uninstall the CLI, then reinstall it.

If you choose to install using NPM, you don’t get the benefit of auto-updates. To uninstall the CLI if you used the DMG installer, download and run the GIST uninstall script: https://gist.github.com/dcarroll/318e5f2d44fb6c2e612dd8d817473cdb

Installation instructions: https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_install_cli_macos.htm

NPM installation instructions: https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_install_cli_npm.htm

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), Powershell, and Windows Subsystem for Linux (WSL) for Ubuntu. There are known issues in the cygwin and Min-GW environments. 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.

Cannot Pull Some Source in Empty Enterprise Edition Scratch Orgs
Description: Scratch orgs don’t have sample data by default. If you create an empty Enterprise Edition scratch org, an error displays if you pull some source, such as custom profiles.
Workaround: In the scratch org definition file, add hasSampleData.
1"hasSampleData": "true",
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

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.
Converting Source for Some Custom Objects Drops XML Namespace
Description: You might see an XML syntax error when pushing some custom objects to a scratch org:
1Error parsing file: The prefix "xsi" for attribute "xsi:nil"
Workaround: Try one of these options:
  • Remove the references causing the issue from the <my object>.object-meta.xml file in your project, then push your source again. For example, <searchResultsAdditionalFields xsi:nil="true"/>
  • Remove the references from the retrieved metadata source so they don't get converted during force:mdapi:convert.
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>.

Incorrect Status Message After Making a Fine-Grained Modification to a Custom Object
Description: Let’s say you make a fine-grained modification to a custom object in your scratch org, such as changing one of its field sets. When you run force:source:status or force:source:pull, the status message about the item you modified is sometimes incorrect. In our example, the field set might be marked as Remote Add even though it is already part of your source.

Workaround: None.

Pushing After Removing a Permission Set Locally Causes “Unknown” Error
Description: If you remove a permission set from your local project, then run the force:source:push command, you see the error message: Unknown.

Workaround: None.

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.

Locked Packages Can Only be Installed in Scratch or Sandbox Orgs
Description: You can create three types of second-generation packages. You can install managed packages or unlocked packages in any org. Locked packages are in a pilot release and you can install them only in a sandbox or scratch org.

Workaround: None.

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.